Spec + Task 作为「开发协议层」：Rust 大模型辅助的标准化、harness 化与可回滚
摘要：前文《7.5 万行 Rust 的 Spec 工程实践：用大模型写 Rust 时，如何把「教程味」挡在仓库外 》侧重 Spec 如何把教程式默认值挡在仓库外（unwrap、分层、反幻觉）。本文补同一套体系里另一半：tasks/ 如何把一次改动变成可绑定、可审计、可机械校验的「任务束」——整体更接近 harness 编程：不是再写一篇 Rust 教程，而是约定 输入（任务类型 + 注入 spec）→ 过程留痕（制品）→ 输出门槛（命令证据 + 校验脚本） 的闭包，使大模型在 monorepo 里的行为 可标准化、可复盘、可回滚。
关键词：Spec 注入；任务制品；harness；可审计；回滚；Rust；大模型辅助开发
附图一：协议层在仓库中的位置（架构总览）
spec/ 与 tasks/ 构成 开发协议层：与具体 crate 实现解耦，但被编辑器规则与 CI 自上而下约束；实现层仍落在 crates/ 与普通文档中。
附图二：从需求到合入的主流程（harness 闭环）
一次 非琐碎 改动在协议层上的理想路径：先分类与注入 → 再落任务制品 → 再写实现 → 最后用命令与脚本证明「形状 + 行为」。
一、为什么要单独谈 Spec + Task：教程解决「怎么写」，协议解决「在什么约束下算做完」
教程与示例回答的是：语法与 API 怎么用。
仓库级 Rust 开发在 AI 辅助下真正痛的是：谁在什么边界内、以什么证据宣称完成。
- Spec：短、可注入、按任务类型组合 —— 相当于 不变量与风格的多条「测试夹具说明」，在写代码之前进入上下文。
- Task：
TASK.md/PRD.md/CONTEXT.md/STATUS.md/REVIEW.md+board.md—— 相当于 一次改动的执行合同与飞行记录，把「模型当时怎么理解需求」从聊天记录里 抽出来、落盘、可对 diff。
二者合在一起，才是「少教程味、多工程味」：少讲怎么循环 Vec，多讲本轮改动的验收、风险、验证命令与回归范围。
二、harness 类比：Spec 是夹具说明，Task 是试次记录，CI 是机械探针
在测试语境里，harness 通常指：固定环境、固定入口、固定断言，把被测单元放进可重复的实验架。
映射到 SkillLite 仓库：
| Harness 要素 | 在本仓库的落点 |
|---|---|
| 固定「实验架」说明 | spec/*.md + spec/README.md 的注入路由（任务类型 → 必带哪些 spec） |
| 试次边界（本轮测什么） | tasks/TASK-.../TASK.md 的 scope 与 acceptance criteria |
| 假设与约束（环境、不做什么） | CONTEXT.md、PRD.md |
| 过程时间线（谁何时做了什么） | STATUS.md 的 Timeline / Checkpoints |
| 合入前探针（形状 + 部分语义） | python3 scripts/validate_tasks.py、以及 spec 要求的 cargo fmt / clippy / test 等 可粘贴输出的命令 |
注意：harness 不保证业务绝对正确，它保证的是 「宣称完成」必须经过同一套机械与文书门槛，从而把大模型从「叙事型完成」拉回到 「证据型完成」 —— 这与前文中的 verification-integrity 一脉相承，Task 只是把证据 挂到具体交付单元上，避免全仓共用一个模糊 TODO。
三、可审计：审计的不是「模型有没有思考」，而是「思考结果是否外化为可 diff 制品」
「可审计」在工程上应可操作，否则会变成口号。建议的可审计最小集是：
- 意图与边界可审计：
PRD.md（做什么/不做什么）与CONTEXT.md（技术约束、兼容面）是否在合入前与最终实现 一致或显式标 N/A 并说明。 - 进度与检查点可审计：
STATUS.md是否包含结构化段落（本仓库由validate_tasks.py约束 Timeline / Checkpoints 等），而不是只有一句「完成了」。 - 完成与合入态度可审计：
REVIEW.md是否包含 Merge readiness 等可检索子串，与tasks/board.md状态 同步。 - 验证可审计：
TASK.md/STATUS.md中是否留有 真实命令输出或等价物（与verification-integrity对齐），而不是模型自述「已跑过测试」。
这样，Code review 与事后复盘时，审阅者优先看 制品目录 + diff，而不是在 IM 或 Agent 面板里考古。大模型的「思考」不必逐 token 存档，但其可驱动工程决策的结论必须落在上述文件里 —— 这才是可规模化审计。
附图三：可审计路径（从易失对话到可 diff 制品）
四、稳定性：Task 如何把「一次会话」变成「可恢复的项目状态」
稳定性来自 状态外置：
- 会话内状态：易失、难合并、难并行。
- 任务外置状态：
tasks/TASK-.../与board.md在版本控制中与其他代码 同仓演进，合并冲突以文本形式出现，可被工具与规范约束。
对多子系统 monorepo，这意味着：
- 中断后换人接手：读
TASK+STATUS即可恢复上下文，而不依赖上一任与模型的私聊记录。 - 并行开发：不同
TASK-...目录天然隔离「本轮叙事」，减少「两个 Agent 改同一篇巨型 TODO」的踩踏。
这与 harness 一致：每次试次有编号、有目录、有入口，而不是一锅粥。
附图四：任务生命周期（状态机）
与 tasks/README.md 一致；blocked / cancelled 未画全分支，主路径用于理解「何时允许宣称 done」。
五、可回滚：协议层不替代 Git，但让「回滚什么」更清晰
回滚代码：Git revert / reset 仍是真相源。
Spec + Task 的价值在于定义 回滚的语义单位：
- 若一次 PR 对应一个清晰
TASK-...，回滚时除代码外，可同步 revert 任务制品与 board 条目，避免「代码回去了、文档与 board 仍宣称已交付」的幽灵状态。 - 若采用分支-per-task 的工作方式，任务目录随分支走，合并即 把协议层产物一并合入，历史图谱上 代码与 TASK 叙事同一次提交或可追溯链。
这不是新工具链，而是 约定「任务束」与「合并单元」对齐，降低回滚后的认知负担。
附图五：回滚语义（Git 与任务束对齐）
六、标准化：少写教程，多写「路由表 + 完成门」
可复制、低教程味的标准化，建议只抓三件事（与 SkillLite 仓库现状对齐）：
- 路由表：
spec/README.md—— 任务类型 → 注入哪些 spec；先分类再写代码。 - 完成门：
verification-integrity+tasks/README.md中的 Completion Gate +validate_tasks.py—— 先定义什么叫证据，再允许宣称 done。 - 范围声明：
spec/README.md中的 Repository scope —— 明确spec/tasks只服务 本仓工程，避免与桌面运行时配置混谈（减少无效争论与错误注入）。
编辑器侧再用 .cursor/rules/spec-injection-index.mdc 等把「打开仓库即看到路由」固定下来，形成 人机共用的同一套协议，而不是每人一份私有「提示词教程」。
七、与纯「长系统提示词」方案的对比（为何仍要 Task）
仅依赖超长系统提示词的问题：
- 版本不随 PR 走：提示词在客户端或私域，review 难以对齐「当时到底约束了什么」。
- 难以机械校验：没有
validate_tasks.py这类对 文件形状 的低成本探针。 - 并行与中断差：没有
TASK-...这种天然分桶。
Spec + Task 把可标准化部分 放进仓库与 CI 能触达的路径，长提示词只保留 会话级临时上下文 —— 二者分层，才像 harness 而不是「一篇读完算完」的教程。
八、总结
- Spec：把 Rust 与架构的 Must / Must Not 变成可注入、可路由的短协议（前文已展开技术向细节）。
- Task：把一次交付变成 有目录、有验收、有时间线、有合入态度 的 harness 试次，支撑 可审计、可并行、可回滚语义。
- 合在一起：减少「教程式代码生成」，增加 「协议式工程生成」 —— 大模型仍写实现，但 完成定义与留痕方式 由仓库统一收束。
若只读一篇入门，建议顺序：先读 Spec 工程实践 建立技术护栏认知，再以本文为轴把 tasks/ 当作同一护栏下的「试次与证据容器」来用。
参考（仓库内路径）
spec/README.md— 注入路由与仓库范围tasks/README.md— 任务生命周期与 CI 校验说明scripts/validate_tasks.py— 任务制品形状 harness.cursor/rules/spec-injection-index.mdc— 编辑器侧与 spec 对齐- 前文：7.5 万行 Rust 的 Spec 工程实践：用大模型写 Rust 时，如何把「教程味」挡在仓库外
- Github项目
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
2
0- 0
已为社区贡献11条内容
所有评论(0)