来源信息

阅读范围

  • 全文，覆盖解除过度约束、六组新旧做法、上下文分层与简化建议。

从约束堆积到按需信息

上下文包含系统指令、项目说明、技能、记忆和参考，并非只有当前提问。文章报告对特定新模型删减系统提示后，内部编码评估未见可测损失；重点是检查过时、重复和相互冲突的要求，而不是追求越短越好。

六组变化

  • 规则转向判断：例如注释密度应参考周围代码，而非一律禁止多行注释。
  • 示例转向接口：清楚的参数、状态枚举和约束可比大量示例更有表达力。
  • 全量前置转向渐进披露：验证、审查资料在需要时加载，长指南拆成可发现的文件。
  • 重复强调转向简洁工具描述：工具用法集中在接口附近，减少多处重复。
  • 项目文件中的记忆转向自动记忆：区分稳定规则和会话经验。
  • 简单规格转向丰富参考：代码、测试、HTML 原型与评价量表也能表达预期。

分层落地与限制

系统提示交代产品身份和工作环境；项目说明保留用途与独有陷阱；技能承载按需知识；参考文件描述当前任务。文末提出简化检查工具，但本文未运行它，也未修改任何配置。

这些经验针对文章所述模型和内部评估，不能证明所有规则都多余，也不能直接推广至其他模型。自动记忆可能过时，参考代码也可能有缺陷；高风险约束、用户明确要求和权限边界仍需保留。减少冲突应先厘清含义，不能擅自删除不理解的限制。

游戏开发应用建议

以下为整理者建议，非原文实测，也不表示已经实施。

给要塞 NPC 项目整理上下文时，可让入口只交代资源所有权、任务打断原则和资料位置。把生产、战斗、寻路的细节分开，当前任务只引用相关部分；使用状态枚举和可运行测试表达规则，避免在多个文件里重复解释同一流程。

玩法参考宜同时给出体验目标与可检查的例子。测试能约束资源归还和状态恢复，却未必能判断节奏是否有趣；评价量表与人工试玩需补上体验维度。实验性原型也应标明哪些行为只是示意。

可先挑一个小场景，比对整理前后的漏约束、误解、查找次数和验收结果，再决定是否继续精简。保留冲突记录与规则来源，便于回查；不要把“模型更强”当作放宽存档、资产或发布权限的理由。

小结

把稳定约束、任务参考与历史经验放在合适位置，提供可发现且可靠的信息，比不断增加通用指令更值得验证。

参考来源

相关笔记