context-infra 检查与复盘infra.guiming.net · 全内容自包含呈现 · 生成于 2026-07-21 16:28 UTC

报告易读性自检(术层 · 实现/走查报告的内容组织)

Z3 全文↑ Z2 条目

术-内容 · 术层 skill 全文

← 返回术层 skill 索引 · 返回方法论区

本页是 <code>rules/skills/drafts/bestpractice_report_readability.md</code> 的逐字投影(仅隐私清洗,零改写)。

时点提示:本页是仓内文件 rules/skills/drafts/bestpractice_report_readability.md 的逐字投影(仅做隐私清洗:仓库根绝对路径→相对路径、家目录→~/;除此零改写)。若源文件后续有修订,以仓内真源为准。

报告易读性自检(术层 · 实现/走查报告的内容组织)

元数据

先纠正一个误解:易读性不是小白化

易读性不是把内容简化到小白能懂。是清晰完整地记录变化,让读者(用户本人和队友)一遍读懂发生了什么。重要概念可以在不同段落适当重复,方便理解。细节可以专业,但必须记录清楚,不回避、不简化掉真实实现。目标是清晰,不是浅。

报告必须讲清的四件事

一份记录工作的报告,缺一件就不合格:

  1. 任务怎么做的:给路径,不只给结论。
  2. 改了哪些:说清改的是什么内容,不是只贴 diff。
  3. 之前 vs 之后:同一对象改动前后的对比。
  4. 遇到的问题:完整记录踩的坑和怎么解决的。

贯穿这四件的是一条证据链(用户 05-27 原话):报告要呈现"基于某次运行 / 测试结果 → 做了什么修改 → 怎么满足了需求"。这条链断了,报告就退化成结论堆砌。

变化优先用图表现

人对图像理解更快。"之前 → 之后"的变化优先用图(流程图、架构图、对比图、时间线),不要纯文字描述。核心改动和外围改动分开画,不要一锅烩。

产出前的 look-back 自检(硬要求)

报告不能凭记忆写,先回看真实过程记录再写:

报告里每个"改了 X"都要能在记录里找到落点。这一步是防止报告凭印象漂移、报喜不报忧的关键,也是用户反复纠正过的点。

不写进正式报告的(降噪)

例外分流:landing-pipeline 任务报告必须逐字记录原始 prompt,见 workflow_report_writing_matrix 的"landing-pipeline 任务报告约定"。

易读性卡点验证

派一个无背景 sub-agent 通读初稿,挑它真卡住的地方:A 术语没解释 / B 指代不明 / C 概念不充分 / D 假定背景。口径是清晰记录(读者不卡、能复现你的理解路径),不是小白都懂。prompt 模板复用 skill bestpractice_final_report 附录 1,格式无关,任何草稿都能跑。

验收标准(无背景 agent 也能判定)

边界(不做什么)

已知陷阱(真实,带出处)

<!-- created 2026-05-31 by zlx: 易读性=完整记录变化(重构自小白可读版),配 COMMUNICATION.md 道层 -->


← 返回术层 skill 索引 · 返回方法论区