# 「开发日志」提示词：让AI编码决策可审计

- 来源：meng shao (@shao__meng)
- 发布时间：2026-05-19 08:41
- AIHOT 分数：79
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmpbx9x5v1b1yslnzc24m4139
- 原文链接：https://x.com/shao__meng/status/2056535561540948056

## 精选理由

这个提示词解决了AI编码最棘手的问题，spec永远写不全，决策藏在diff里。把判断变成可审计的文件，review时直接对照笔记而非逆向工程，做coding agent的值得随时复制。

## AI 摘要

针对AI协作编码中“规格永难完整”与“决策无法追踪”的核心矛盾，此提示词提出了第三条路径。它要求AI在实现需求时同步维护一份结构化文档，明确记录设计决策、对规格的偏离、考虑过的权衡以及待确认的开放性问题。这种方法的关键在于将AI执行过程中的隐性判断显式化、文档化，从而让Code Review可直接对照决策笔记，而非逆向工程代码。它不仅降低了模型的过度澄清倾向，更通过提供结构化产物，建立了一种可审计、可协作的人机开发新范式。

## 正文

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 自己倡导的"人机协作"范式

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

### 引用推文

> Thariq：a prompt I've been using a lot recently: implement <SPEC> and while you do, keep a running implementation-notes.html file (or markdown) with decisions you had t...