ultracode 使用建议
以下均为去标识后的合成模板，不含真实会话引文、会话标识、本机路径或可回查 commit。 模板用于解释提示词结构，不构成效果或成本基准。 阅读对象:ultracode 用户
0. 使用总则
Section titled “0. 使用总则”一个可执行的委托通常包含目标、范围、阶段验收、汇报格式、失败处理与成本分配。本页给出一个组合模板和六个基础模板，示例均为合成内容。
1. 组合参考:完整任务模板(覆盖全部缺环)
Section titled “1. 组合参考:完整任务模板(覆盖全部缺环)”/ultracode 你是{角色}。实现 {目标},按 {feature 列表} 拆分。
工作流:每个 feature 执行 plan → code → review → fix → test;全部完成后执行集成 test fix test。
模型分配:plan 用 sonnet 产出设计文档;code 用 sonnet;review 用 haiku 分三路并行(维度 1/维度 2/维度 3);fix 用 sonnet;test 用 haiku。
约束:{规范清单}范围排除:先不做 {X}失败处理:单个 feature 卡住超过 {N} 轮,停止并汇报汇报格式:每阶段结束回报(产物路径 / 改动文件 / 遗留风险),最终汇总 markdown完成动作:全部通过后提交 git开始吧各要素对应的缺环
Section titled “各要素对应的缺环”| 模板要素 | 补齐的缺环 |
|---|---|
| plan 产出设计文档、review 对照文档 | 阶段验收标准(缺环 1) |
| 汇报格式(产物路径/改动文件/遗留风险) | 汇报格式(缺环 2) |
| review 输出问题清单进入 fix | 阶段间契约(缺环 3) |
| 失败处理(卡住 N 轮停止汇报) | 失败处理(缺环 4) |
| 模型分配 | 成本分配(缺环 5) |
一条消息可以描述 feature 级并行、阶段级串行、模型分层、失败收敛和汇报结构。实际能否无人值守完成取决于权限、外部依赖、失败状态和宿主进程生命周期。
阶段验收、汇报和阶段契约减少结果错位；失败处理与模型分配用于约束执行范围。它们是否减少返工或成本需要在具体项目中测量。
2. 委托启动模板(最小可用)
Section titled “2. 委托启动模板(最小可用)”/ultracode 审查 commit <target-commit>，只报告问题，不修改文件| 要素 | 本示例 | 说明 |
|---|---|---|
| 动词 | 审查 | 单一动作词,不含过程指令 |
| 目标 | commit <target-commit> | 一句话，精确到可验证对象 |
| 边界 | (隐含)只审查该 commit | 目标即边界 |
系统收到委托后自主决定编排:单任务则单 agent 执行,可拆分则拆分并行。执行完成后返回结果摘要与产出物位置。你不需要写任何过程指令,规划轮次被压缩到一条消息内。
委托式结构把「目标」与「执行路径」分开：你定义结果和边界，系统提出路径。规划是否节省成本取决于任务复杂度；关键是让规划结果接受验收标准约束。
3. 标准流水线模板(plan → code → review → fix → test)
Section titled “3. 标准流水线模板(plan → code → review → fix → test)”/ultracode 实现 {目标}。使用 workflow 构建 plan → code → review → fix → test 流水线完成。约束:{规范/协议清单}范围排除:先不做 {X}完成后:提交 git,汇报阶段产物摘要合成示例：
/ultracode 按 <design-doc> 实现服务端能力。把每个 feature 分成 plan、code、review、test，最后执行服务端集成测试。先不做 TUI；遇到阻塞就停止并汇报，不自动提交。| 要素 | 作用 | 缺省的后果 |
|---|---|---|
| 阶段序列 | 定义质量关口与顺序 | 无 review 时,错误直接流入下游 |
| feature 拆分 | 并行度来源 | 单 agent 串行,总时长 ×N |
| 范围排除(不做 tui) | 防越权 | agent 可能实现未要求的部分 |
| 完成动作(提交 git) | 收尾契约 | 完成后停在中间状态 |
每个 feature 依次经过五个阶段:plan 产出设计文档 → code 按文档实现 → review 对照文档与约束检查 → fix 按问题清单修改 → test 执行验证。feature 间并行,集成阶段串行。每阶段产出(设计文档、问题清单、测试结果)自动作为下一阶段输入。
阶段依赖(审查必须先于修复)由编排层保证,你每次只需更换目标与范围,模板本身不再重新设计——样本中该模板被复用了 10 次,且呈现清晰的两周进化轨迹(单环节 → 五段完整)。五个阶段各自解决的问题:
- plan:把「做什么」显式化,后续阶段有了对照基准,review 才有审查对象
- review:质量关口,发现的问题以清单形式进入 fix,而不是口头流转
- fix + test:修复必须伴随验证,防止「修好 A 弄坏 B」的回归
4. 审查模板(焦点公式:范围 + 维度 + 标准 + 输出 + 后动作)
Section titled “4. 审查模板(焦点公式:范围 + 维度 + 标准 + 输出 + 后动作)”/ultracode 审查 {范围}。分三路并行:维度 1 一路、维度 2 一路、维度 3 一路。标准:{引用具体规则或规范}输出:问题清单(文件/行号/严重度/建议)后动作:只报告,不修改对照：焦点缺失的合成版本
Section titled “对照：焦点缺失的合成版本”/ultracode 使用 workflow 编制一个审查小组，审查代码风格和性能问题（CPU MEM IO），方向为随意要素拆解与缺失后果
Section titled “要素拆解与缺失后果”| 要素 | 缺失后果 |
|---|---|
| 范围(审什么) | 审查者不知道看哪里,四处游走 |
| 维度(看什么) | 审查者退回自身默认标准(命名/注释),与你的关注点错位 |
| 标准(什么算错) | 无判定依据,产出「我觉得有问题」式主观报告 |
| 输出格式(清单) | 报告无法自动进入修复阶段,人工转译 |
| 后动作(报告/修复) | 审查与修复之间无契约,衔接断裂 |
「方向随意」版本会让各 agent 自选维度，可能出现方向重叠或遗漏。没有受控实验时，不能给这种风险附上覆盖率或成本数字。
焦点完整版本:三路并行、维度正交、清单格式统一,汇总可直接合并去重,问题清单可自动进入 fix 阶段。覆盖率 = 维度数,可合并性由输出格式保证。
审查的本质是搜索问题,搜索效率由搜索空间决定。焦点公式中的每个要素都在压缩搜索空间:范围压缩空间广度,维度压缩空间深度,标准消除判定歧义,输出格式保证结果可消费。注意一个边界:「方向随意」不是错误,是工具——它只适用于「发现未知问题」的探索型任务;用于「验证已知关注点」的任务时,开放性与目标冲突。判断标准:你的任务是「看看有什么问题」还是「检查边界是否维持」,前者可开放,后者必须给维度。
5. 模型分层模板(成本分配)
Section titled “5. 模型分层模板(成本分配)”模型分配:plan 用 sonnet 产出设计文档;code 用 sonnet;review 用 haiku 分三路并行;fix 用 sonnet;test 用 haiku合成示例：
/ultracode 编制一个 workflow，大幅度采用 sonnet 帮你执行代码编写， 注意分配 haiku review| 阶段 | 建议模型 | 依据 |
|---|---|---|
| plan | sonnet | 一次设计错误全链路污染,是代价最高的错误 |
| code | sonnet | 主体实现,正确性直接决定修复成本 |
| review | haiku × N | 检测型任务,低成本 × 多路 = 覆盖率 |
| fix | sonnet | 修复引入回归的代价高于审查本身 |
| test | haiku | 执行验证,标准化程度最高 |
工作流执行期间,各阶段 agent 按分配使用对应模型;审查阶段因 haiku 成本低,可以用更多路并行而总成本不升。成本曲线从「全 sonnet 单路」变为「重写轻审」形态:质量关键路径上成本不降,重复性路径上成本降到最低。
模型分层的原理是「认知负载与模型能力的匹配」:plan/code/fix 是生成型任务,错误代价高,值得强模型;review/test 是检测型任务,可并行分摊,强模型的高边际收益低。样本中该技巧只被使用 1 次且从未嵌入流水线模板——这是成本优化的最大空白。该模板与其他模板正交,可直接嵌入第 3 节流水线,零执行轮次代价。
6. 约束与边界模板(防越权、防过度执行)
Section titled “6. 约束与边界模板(防越权、防过度执行)”范围排除:先不做 {X}，其余均实现红线:只读审查，不要修改文件停止条件:遇到问题就停止，汇报后等我确认完成动作:完成后提交 git每一条约束都在执行前生效:范围排除阻止 agent 实现未要求部分;红线阻止修改性动作;停止条件让失败路径在第一步就收敛;完成动作保证收尾状态确定。约束的表达位置在委托的第一段,不在执行中补充。
agent 的默认行为是「做完整个任务」——没有范围排除时,「其余均实现」之外的隐性边界会被 agent 自行推断,推断结果不可控。约束前置的本质是把失败模式的探索成本转移到执行前:越权返工(agent 改了不该改的)的代价是修改 + 回滚 + 重新对齐,是三种返工中最贵的。全部样本中,约束都附着在委托开头,且与任务规模正相关——任务越大,边界表达越重要。
7. 反馈模板(delta 反馈)
Section titled “7. 反馈模板(delta 反馈)”{哪里不对} + {期望方向},不重述需求合成示例：
"不是, 是x" 的风格非常多, 你没消除掉呀agent 收到增量信息后,在现有上下文中定位问题并修正,不重新扫描需求全文。反馈轮次 = 问题数,不随上下文长度增长。
委托 + 约束已在上下文里完整定义了需求,反馈再重述需求属于重复传输——上下文每轮递增,重复即成本。delta 反馈只传「差异信息」:位置 + 期望。样本中的反馈全部符合此结构,平均长度低于 60 字符,是全部提示词中信息密度最高的一类。
附:模板适用性边界
Section titled “附:模板适用性边界”- 任务有强时序依赖(如 B 的输入依赖 A 的输出)时,流水线模板天然匹配;任务本身很简单(改一行代码)时,流水线拆分的开销大于收益,应退回第 2 节委托模板
- 模型分层对成本敏感场景(长流程、多路并行)收益显著;对单 agent 短任务,分配指令本身是开销
- 审查焦点公式中的「后动作」若为「只报告」,配合第 7 节反馈模板使用,可形成人机接力;若为「修复并复验」,则直接嵌入第 3 节流水线