流程感知生成：轻量增强开发任务

August 14, 2026 · View on GitHub

目标

增强现有 code2skill-generate 的业务决策边界识别，使复杂目标能够更稳定地区分：Agent 判断与补问、用户确认、可独立调用的 Tool、Function 内部确定性步骤、Host 策略、运行时硬约束，以及完成或停止条件。

本轮优化默认生成流程，不新增 strict generate 命令，不改变 strict-export-v1 的审计含义，也不通过机械拆细 Tool 增加模型推理次数。

开发边界

  • 保持当前调用方式：/skill:code2skill-generate 生成 <源码范围>。
  • 默认产物仍是精简的 Function、MCP、Skill、测试和安装说明。
  • 决策边界图只作为生成过程中的临时分析，不进入交付包。
  • 普通业务校验继续由后端负责，响应原样交给 Consumer Agent。
  • 只有源码明确证明不可绕过的身份、来源、事务、单次凭证、顺序或类似硬约束时，才生成确定性 Guard。
  • 页面顺序、普通确认框、普通 POST、后端拒绝或共享查询本身，不得自动升级为硬 Workflow。
  • 不新增 Canonical/Goal Contract、Capability Graph、审计报告、验证矩阵或其他默认交付文件。
  • 不修改当前未跟踪的文章与图片：docs/juejin-code2skill-launch.md、docs/assets/。

阶段 1：补齐默认生成分析规则

在 skills/code2skill-generate/SKILL.md 中加入明确的“目标决策边界”步骤。

对每个主要用户目标，Producer 必须先在工作记忆中形成最小临时图：

用户目标
→ 已知与缺失信息
→ 查询、选择或校验
→ 分支与停止条件
→ 写入前的展示或确认
→ 写入
→ 源码存在时的结果查询或对账

每个节点必须归入一类：

  1. Agent 判断、追问或选择；
  2. 用户交互或确认；
  3. 可独立命名、调用、复用或停止的 MCP Tool；
  4. 不需要模型参与的 Function 内部确定性步骤；
  5. Consumer Host 策略；
  6. 源码证明不可绕过的确定性 Guard；
  7. 完成、停止或无法确认的结果边界。

该分析必须约束后续 Tool 边界和 Skill 文案，但不要求生成新的中间文件。

阶段 2：明确 Tool 拆分与合并规则

在现有能力设计规则上补充：只有满足下列一项或多项时，才考虑拆出额外 Tool：

  • 中间结果会改变后续调用、分支或请求参数；
  • 能完成一个独立的部分目标，或可被其他目标复用；
  • 前后步骤的权限、副作用或确认要求不同；
  • 中间阶段可以合理停止、等待用户输入或等待用户选择；
  • 写入后存在源码证明的异步状态查询或结果对账能力。

以下情况不拆 Tool：

  • 只是为了让模型多推理一次；
  • 请求组装、字段格式化、RAG 检索内部步骤等确定性实现；
  • 无论中间结果如何，下一步始终相同；
  • 拆开后暴露无业务意义的中间状态；
  • 多个调用属于不可分割的事务边界。

一个 Tool 可以调用多个内部 API；一个 API 也可以支持多个业务 Tool。不要按接口数量机械映射。

阶段 3：增强 Skill 与轻量测试

Skill

对包含多个决策节点的目标，Skill 需要简洁说明：

  • 已知信息、缺失信息以及可安全取得的信息；
  • 哪个结果会影响下一步；
  • 何时可以跳过、停止、继续补问或请求用户选择；
  • 写入前需要向用户展示的影响与选择；
  • 哪些约束只是 Agent/Host 策略，哪些是运行时硬约束；
  • 实际响应不明确时交给 Agent 说明，不能自动转为成功或失败。

Skill 仍然不是固定逐步脚本。信息已经齐全时，不应产生无意义补问或重复查询。

离线测试

仅按目标实际结构增加测试，不建立业务规则组合矩阵：

  • 每个复杂目标一条正常代表路径；
  • 存在跨 Tool 数据交接时，验证选中数据或上游结果正确进入下游请求；
  • 源码证明存在停止分支时，验证 Skill 不会把后续写入描述为无条件步骤；
  • 共享 Tool 不得被错误提升为其他目标的全局前置；
  • 源码证明存在运行时硬边时，保留零外部写入的绕过反例；
  • 普通后端拒绝仍原样到达 Agent。

测试以匿名、跨业务领域的合成案例表达，不出现当前私有业务、页面、接口、字段或路径。

阶段 4：增强轻量 Review 并回归

同步更新 code2skill-review-flow：

  • 仍然只评估代表性主流程，不变成源码精确审计；
  • 对复杂写目标额外检查一个真实存在的关键决策分支；
  • 检查是否遗漏会改变下一步的中间结果、停止点或写入前置；
  • 检查是否把 Agent 补问、用户确认、页面顺序或普通业务校验误生成成 Tool/全局 Workflow；
  • 只有必然提前写入、必然走错分支、缺失必要 Tool/交接或错误增加全局前置时才判 P1；可由 Agent 恢复的引导问题仍为 P2。

新增或更新匿名回归测试，至少覆盖：

  1. 简单只读查询：不能被过度拆分；
  2. 查询/选择/预校验/写入：决策边界正确，补问与确认不是 Tool；
  3. 异步写入/状态查询：只有源码提供状态能力时才生成或说明；
  4. 普通后端校验：不得被虚构成确定性 Guard。

运行当前仓库全部测试和 git diff --check。不得调用真实业务接口。

验收标准

  • 用户仍只需调用原来的 code2skill-generate，无需理解新命令。
  • 简单查询的默认产物规模和步骤没有明显增加。
  • 复杂目标能明确区分 Agent、用户、Tool、Function、Host 与 Guard 的职责。
  • 不把每一步变成 Tool，不以增加推理次数作为拆分理由。
  • 不把普通写操作、页面确认或后端校验自动升级为硬 Workflow。
  • 不增加默认交付文件种类，不恢复重型审计流程。
  • code2skill-review-flow 能发现提前写入、遗漏关键决策边界和错误全局前置，但不会苛求所有业务分支。
  • 匿名测试、全量测试与 git diff --check 通过。
  • 不修改、提交或删除用户现有的未跟踪文章及图片。

协作与交付规则

  • codex-volc-deepseek-flash 负责实际开发，按阶段 1–4 顺序推进。
  • 每完成一个阶段，DeepSeek 必须向 kimi-share-test 汇报：修改文件、关键设计、测试结果、未验证边界，然后等待审核。
  • kimi-share-test 只负责每 15 分钟巡检、独立审核、运行必要的只读检查或测试，并把问题退回 DeepSeek；不得自行修改代码。
  • Kimi 发现问题后给出最小修改要求；DeepSeek 修复并重新汇报，循环至验收通过。
  • 不提交、不推送。最终由 Kimi 汇总阶段结果、全量验证、git status 和遗留边界。
  • 两个会话发送 tmux 消息时必须实际发送 Enter，并在发送后读取面板确认文字已经进入对方会话，不能只停留在输入框。