同步最新文档

2Areas/AI工作流/人类注意力应分配到高杠杆的点.md

@@ -1,11 +1,31 @@
 ## 参考资料
 - [[清华大学 驾驭工程 Harness Engineering 研究报告]]
-	- openAI对于agent开发的建议
+  - OpenAI 对 Agent 开发的建议
 
-## Why？
-- AI Agent产出的代码量太大，人类的注意力已经不能像过去那样逐行代码review，产出速率收到人类review的限制 
+## 核心判断
+- AI Agent 的代码产出速度，已经远远超过人类逐行 review 的速度。
+- 因此，人类注意力不应该继续主要投入在“低杠杆的代码逐行检查”上，而应该转向“高杠杆的约束与表达”。
+- 真正限制系统质量的，往往不是 Agent 写代码的速度，而是需求边界、架构约束、接口契约和验收标准是否足够清晰。
 
-## How?
-- SVG图
-- c4-dynamic文档
-- flow文档
+## 人类应该重点投入的高杠杆点
+- 目标与边界
+  - 先定义要解决什么、不解决什么、什么算完成。
+- 架构与模块划分
+  - 提前收敛模块边界、职责分工、依赖方向，避免 Agent 在实现期自由发散。
+- 接口契约
+  - 明确输入、输出、异常、状态变化，让实现与 review 都有统一基准。
+- 关键流程表达
+  - 用图和结构化文档表达核心链路，比直接 review 大量代码更省注意力。
+- 验收标准
+  - 提前定义“什么结果算对”，比事后追着代码修偏差更有效。
+
+## 适合承载这些高杠杆信息的文档
+- SVG 图
+  - 用来表达系统结构、模块关系、关键路径。
+- C4 Dynamic 文档
+  - 用来描述运行时对象/模块之间如何协作，约束核心交互过程。
+- Flow 文档
+  - 用来描述更细粒度的业务流程、调用顺序和异常分支。
+
+## 一句话总结
+- 人类应把注意力从“审每一行代码”，转移到“定义系统该如何被正确实现”。

2Areas/AI工作流/文档优先编程.md

@@ -1,13 +1,104 @@
+## Why
+- AI 产出代码的速度远远大于人类 review 的速度，所以人应该把注意力聚焦在高杠杆的位置，而不是把主要精力消耗在逐行看代码上。
+- 文档就是这种高杠杆工具。它能用较小的注意力成本，约束 Agent 对需求、边界、架构和实现路径的理解。
+- 参考：[[人类注意力应分配到高杠杆的点]]
 
-## why?
-- Ai 产出代码的速度远远大于人类review的速度，所以人应该聚焦于高杠杆的点，参考[[人类注意力应分配到高杠杆的点]]。而文档就是人可以用最小的注意力就可以规范agent实现需求以及边界的翘点。
-## what?
-- 以策划文档发起
-- 第一个文档：PRD
-	- 内容：
-- 第二个文档：根据访谈内容生成的时序图
+## 核心观点
+- 先写文档，不是为了增加流程，而是为了降低实现偏差。
+- 文档优先编程的本质，是先把“要做什么、为什么这样做、做到什么程度算对”说清楚，再让 Agent 批量实现。
+- 如果文档质量足够高，后续代码实现、review、回溯修正都会轻很多。
 
-## how?
-- 
-- 参考美团AI工作流
-![[美团AI工作流.png]]
+## How
+下面以 OMX 工作流为例。
+
+### 1. 从策划文档发起
+- 输入：策划文档 / 需求文档 / PRD
+- 目标：给后续所有文档一个统一的问题定义和业务背景
+
+### 2. 通过 `$deep-interview` 产出访谈文档
+- 输入：策划文档
+- 产物：访谈文档
+- 作用：
+  - 明确目标、边界、本期做什么、不做什么
+  - 补充约束条件和项目上下文
+  - 沉淀一些和具体项目绑定的技术前提
+- 说明：
+  - 这份文档更像“给 Agent 用的澄清稿”，用来减少需求理解偏差
+
+### 3. 通过 `$alignment-c4-dynamic` 产出 C4 Dynamic 文档
+- 输入：访谈文档
+- 产物：C4 Dynamic
+- 作用：
+  - 描述关键运行时交互
+  - 收敛模块边界、接口约定、架构约束
+  - 形成较粗粒度的技术方案和协作视图
+
+### 4. 通过 `$plan` 产出细化计划文档
+- 输入：访谈文档 + C4 Dynamic
+- 产物：Plan 文档
+- 作用：
+  - 把粗粒度方案继续细化
+  - 明确任务拆解、模块边界、接口约定、实施顺序
+  - 让后续实现不再依赖临场发挥
+
+### 5. 通过 `$ralplan` 产出可执行实现计划
+- 输入：访谈文档 + C4 Dynamic + Plan 文档
+- 产物：Ralplan 文档
+- 作用：
+  - 把前面的信息进一步压实为“面向执行”的实现计划
+  - 让实现阶段的上下文、顺序和约束更集中
+- 当前理解：
+  - 它位于 Plan 和实际编码之间，作用类似“可直接驱动实现的执行蓝图”
+
+### 6. 通过 `$alignment-flow ralplan文档` 产出时序图
+- 输入：Ralplan 文档
+- 产物：时序图 / Flow 文档
+- 作用：
+  - 把关键流程细化到方法、接口、调用顺序和异常分支
+  - 用自然语言 + 流程表达把实现细节前置说明清楚
+
+### 7. 通过 `$ralph ralplan文档` 产出代码
+- 输入：Ralplan 文档
+- 产物：代码
+- 作用：
+  - 按前面已经定义好的文档约束进行实现
+
+### 8. Review 代码，并把偏差回写到文档
+- 如果没问题：
+  - 把前面产出的文档整理后沉淀到项目记忆中
+- 如果有问题：
+  - 先判断问题出在实现，还是出在前置文档本身
+  - 很多偏差并不是 Agent “写错了”，而是上游文档没有把关键约束表达清楚
+
+## 偏差修正回路
+- 如果差异主要出在 C4 Dynamic：
+  - 重新跑 `$deep-interview`
+  - 修正访谈文档
+  - 再回到 C4 Dynamic 阶段继续收敛
+- 如果差异主要出在 Plan / Ralplan：
+  - 重新跑 `$plan` 或 `$ralplan`
+  - 把差异点回写到访谈文档
+  - 再继续推进后续阶段
+- 如果差异主要出在时序图 / Flow：
+  - 重新跑 `$ralplan`
+  - 同时把差异回写到 Plan、Ralplan、访谈文档
+  - 再进入实现阶段
+
+## 实践原则
+- 文档不是“交付物附属品”，而是实现质量的上游控制面。
+- review 不应该只盯代码，也要反查是哪一层文档没有把问题讲清楚。
+- 一旦发现偏差，优先修正文档源头，而不是只在代码层打补丁。
+
+## 参考
+- [[AI-First产研团队的交付路径]]
+  - 需求 / PRD
+  - 技术方案设计
+  - 任务拆解
+![[AI-First描述工作流.png]]
+
+- [[天猫新品团队AI编码实战指南（下）]]
+  - 可对照理解为三类核心文档：
+  - 第一类：需求 / PRD
+  - 第二类：技术方案
+  - 第三类：任务拆分
+![[美团AI工作流.png]]

3Resources/AI/AI-First产研团队的交付路径.md

@@ -35,14 +35,14 @@
 
 六个阶段的核心逻辑不是线性流程编排，而是**上下文逐级收敛、阶段持续校验、结果最终回写**。
 
-| 阶段 | 人的职责 | AI 的职责 | 显性资产（给人的） | 隐性上下文（给下阶段 AI 的） |
-|------|----------|-----------|-------------------|---------------------------|
-| 业务需求 | 定义目标、边界、优先级 | 起草需求内容 | 需求文档 | 业务意图、边界约束 |
-| PRD 设计（write-prd Skill） | 澄清歧义、确认范围 | 生成结构化 PRD | AI 可执行的 PRD | 功能目标、业务规则、验收标准 |
-| 技术方案设计（write-tech-design Skill） | 评审架构可行性 | 产出方案初稿 | 技术方案 + API 契约 | 模块边界、接口约定、架构约束 |
-| 任务拆解（breakdown-tasks Skill） | 确认优先级与依赖 | 拆解为可执行单元 | WBS 任务列表 | 单任务输入/输出/依赖/验收标准 |
-| Daily Coding Agent（编码/单测/CR Skill） | 审核关键逻辑与架构边界 | 编码→单测→CR→修复循环 | 经验证后可交付的代码 | 代码变更记录、新增接口与规则 |
-| 上下文更新（update-context Skill） | 审检沉淀结果 | 回写知识与上下文 | 更新后的知识资产 | 下一轮迭代的全量上下文基线 |
+| 阶段                                 | 人的职责        | AI 的职责        | 显性资产（给人的）     | 隐性上下文（给下阶段 AI 的） |
+| ---------------------------------- | ----------- | ------------- | ------------- | ---------------- |
+| 业务需求                               | 定义目标、边界、优先级 | 起草需求内容        | 需求文档          | 业务意图、边界约束        |
+| PRD 设计（write-prd Skill）            | 澄清歧义、确认范围   | 生成结构化 PRD     | AI 可执行的 PRD   | 功能目标、业务规则、验收标准   |
+| 技术方案设计（write-tech-design Skill）    | 评审架构可行性     | 产出方案初稿        | 技术方案 + API 契约 | 模块边界、接口约定、架构约束   |
+| 任务拆解（breakdown-tasks Skill）        | 确认优先级与依赖    | 拆解为可执行单元      | WBS 任务列表      | 单任务输入/输出/依赖/验收标准 |
+| Daily Coding Agent（编码/单测/CR Skill） | 审核关键逻辑与架构边界 | 编码→单测→CR→修复循环 | 经验证后可交付的代码    | 代码变更记录、新增接口与规则   |
+| 上下文更新（update-context Skill）        | 审检沉淀结果      | 回写知识与上下文      | 更新后的知识资产      | 下一轮迭代的全量上下文基线    |
 
 **关键洞察**：注意"隐性上下文"这一列——需求阶段提供业务意图，PRD 阶段将意图转为结构化约束，技术方案阶段将约束收敛为技术决策，任务拆解阶段再将决策压缩为最小执行单元。到 Daily Coding Agent 阶段，AI 拿到的已不是一个模糊需求，而是一份高度收敛的任务上下文。