Claude Code 核心开发者 Thariq 带来了他自己高频使用的「开发日志」提示词。

@trq212 这段提示词解决了 AI 协作编码中最棘手的结构性问题：规格永远写不完整，但人又无法实时跟踪 AI 的每一个判断。

传统的两种极端都失败：
1. 过度规约：试图在 spec 里穷举所有边界情况——不现实，且拖慢启动
2. 完全放手：让 agent 自由发挥——结果是大量隐性决策埋藏在 diff 里，code review 时才发现，返工成本极高

这个提示词走的是第三条路：承认歧义不可避免，把"判断"这个动作本身变成可审计的产物。

这种做法为啥有效？
· 降低模型的"过度澄清"倾向：模型不必反复打断你问问题，可以自主推进
· 把隐性决策外化：原本藏在代码里的"为什么这样写"被显式写出来，review 时直接对照笔记，而不是逆向工程 diff
· 结构化的四个维度正好覆盖了实施中所有"非代码信息"：
· Design decisions = 填补 spec 的空白
· Deviations = 偏离 spec 的地方（最危险，必须显式）
· Tradeoffs = 没走的路（防止 reviewer 重复思考同样的备选）
· Open questions = 需要人类回环的点
· HTML/Markdown 作为载体：轻量、可读、可与代码同 PR 提交，不需要额外工具

值得借鉴的 prompt 设计原则
· 给模型一个"合法的出口"，而不是逼它在歧义前停下或瞎猜
· 要求结构化产物（四个明确分类），比开放式"写点笔记"质量高一个数量级
· 用单独文件而非 inline 注释——保持代码干净，同时让元信息集中、可搜索
· 二次迭代本身是个示范：第一版凭直觉写，第二版让 Claude 帮忙结构化——这就是这条 prompt 自己倡导的"人机协作"范式

提示词原文：
实现 <SPEC>。在编码过程中，维护一个持续更新的 implementation-notes.html 文件，记录所有我应当知道的实现与 spec 偏离或解读的情况，包括：
· Design decisions: 你在 spec 含糊之处做出的选择
· Deviations: 你故意偏离 spec 的地方及原因
· Tradeoffs: 你考虑过的备选方案以及你选择当前方案的理由
· Open questions: 任何你想要我确认或修改的内容