改动决策日志模板
你是结对编码记录助手。在改文件前先输出中文决策日志，供人建立工作理解。禁止建议无说明的大范围重构。
输出：
## 本轮目标（一句话）
## 为何这样改
## 影响面（模块/接口/数据）
## 回滚点
## 可读摘要（给未参与同事）
## 超出范围则「拆分建议」
## 非目标（不大爆炸改动、不跳过日志）
任务与仓库线索：
{{task_and_context}}场景说明
Agent 写码快，但「黑盒大改」会让人失去对代码的工作理解。约定每轮改动附决策日志（为何改、影响面、回滚点）与可读摘要；单次 PR/提交保持小而可审。禁止无注释、无说明的大爆炸改动。目标是人机协作后仓库仍可被人独立维护与调试。
案例叙事
01他们做了什么
Hacker News 评论（item 50158650，用户 iamwil；父帖 Ask HN: How to deal with shipping AI-written code you don't understand?）援引 Peter Naur「程序设计是在头脑里建立系统的工作理论」：Agent 代写后，人若不再亲手摸代码，「工作理解」会被抽走。作者自述因此重做工作流，四条原则：（1）审讯/访谈式设计与规格，让 Agent 先问清歧义（如 /grill-me）；（2）人只拍板真正有差异化的决策，琐碎与无差异化子系统可交给 Agent；（3）用 Agent 生成解释页、测验与仿真，逼自己弄懂再扩展；（4）编码环加 guardrails（lint/类型/钩子）与按特性变化的 verifiers（测试、形式化轨迹等）。公开评论未给出理解保留率、回滚率或缺陷密度等量化。
国内落地对齐「每步可接手」：开工前约定摘要模板与单次改动范围上限；Agent 每步先交决策日志（为何改、影响面、回滚点）与可读 diff 说明再改文件；人据日志抽查关键路径后再合并。硬约束：禁止无注释、无说明的大爆炸改动；发现即打回拆小步；决策日志与代码同仓，便于飞书/企微同步给接手人。
02实际效果
- 源未披露「工作理解」保留率、缺陷密度、回滚率或人审否决率等量化；公开评论侧重工作流原则与可验证护栏的经验描述。
- 作者自述：改用访谈式规格、人拍板关键决策、解释/测验/仿真巩固理解，并以 guardrails + verifiers 约束编码环（评论陈述，非我方实测）。
- 团队可把 Agent 写码收成「小步 + 决策日志 + 人抽查」；仓库目标仍是人可独立维护与调试，而非黑盒一次性大改。
03值得知道
- 公开源未给出可复用的理解或质量基线，上线后用自有关键路径抽查与事故复盘，勿把「有日志」等同于「人已理解」。
- 硬约束：禁止无注释大爆炸改动；单次改动超范围上限必须拆分；合并前人对关键路径抽查；决策日志须同仓可检索。
- 解释页与测验仍可能含模型幻觉；形式化/轨迹测试不能替代业务验收；飞书同步日志时勿泄露生产密钥。
04可复制提示词
接手抽查飞书卡
根据决策日志与 diff 说明生成飞书/企微接手抽查卡（≤180 字）：改动范围、必看文件、建议手测路径、是否允许合并。若缺日志或疑似大爆炸，输出「打回拆分」。不要编造未提供的覆盖率数字。
材料：
{{log_and_diff_summary}}怎么做
- 开工前约定摘要模板与单次改动范围上限
- Agent 每步输出决策日志与可读 diff 说明后再改文件
- 人据日志抽查关键路径，确认理解后再合并
实用提示
- 决策日志与代码同仓存放，便于日后接手
- 发现无注释大爆炸改动一律打回，拆成小步重做