摘要 ：前文《7.5 万行 Rust 的 Spec 工程实践：用大模型写 Rust 时，如何把「教程味」挡在仓库外 》侧重 Spec 如何把教程式默认值挡在仓库外 （unwrap、分层、反幻觉）。本文补同一套体系里另一半：tasks/ 如何把一次改动变成可绑定、可审计、可机械校验的「任务束」 ------整体更接近 harness 编程 ：不是再写一篇 Rust 教程，而是约定 输入（任务类型 + 注入 spec）→ 过程留痕（制品）→ 输出门槛（命令证据 + 校验脚本） 的闭包，使大模型在 monorepo 里的行为 可标准化、可复盘、可回滚。
关键词：Spec 注入；任务制品；harness；可审计；回滚；Rust；大模型辅助开发
附图一：协议层在仓库中的位置（架构总览）
spec/ 与 tasks/ 构成 开发协议层 ：与具体 crate 实现解耦，但被编辑器规则与 CI 自上而下约束 ；实现层仍落在 crates/ 与普通文档中。
实现与交付物
机械门槛
开发协议层（本文明确定义）
入口：人机共用上下文
注入到提示词前
验收与证据挂载
.cursor/rules
spec-injection-index 等
CLAUDE.md / AGENTS.md
（指针到 spec）
spec/README.md
任务类型 → 注入映射
spec/*.md
Must / Checklist
tasks/TASK-.../
TASK · PRD · CONTEXT
STATUS · REVIEW
tasks/board.md
全局状态板
scripts/validate_tasks.py
制品形状
cargo fmt / clippy / test
等可粘贴证据
crates/**/*.rs
docs / README
附图二：从需求到合入的主流程（harness 闭环）
一次 非琐碎 改动在协议层上的理想路径：先分类与注入 → 再落任务制品 → 再写实现 → 最后用命令与脚本证明「形状 + 行为」。
是
否 · 轻量
未过
通过
需求 / 缺陷 / 重构项
判定任务类型
architecture · security · agent · mixed ...
按 spec/README.md
列出 Injected Specs
是否非琐碎
或维护者严格模式?
创建或复用
tasks/TASK-.../
Task ID: N/A
PR 内仍写清验证与回归
TASK / PRD / CONTEXT
范围与验收基线
实现：Rust / 配置 / 文档
机械验证
fmt · clippy · test 等
更新 STATUS / REVIEW
附真实命令输出
validate_tasks.py
通过
tasks/board.md
与 REVIEW 一致
完成门
spec + 任务清单
合入 PR
一、为什么要单独谈 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 制品）
审阅入口
落盘 · 可 diff · 可检索
易失 / 难作为合入依据
外化结论
（人工或 Agent 整理）
Agent 多轮对话
与临时推理
PRD.md
做什么 / 不做什么
CONTEXT.md
技术边界
TASK.md
验收标准
STATUS.md
Timeline · Checkpoints
- 验证证据
REVIEW.md
Merge readiness
Code review
先看制品与 board
四、稳定性：Task 如何把「一次会话」变成「可恢复的项目状态」
稳定性来自 状态外置：
- 会话内状态：易失、难合并、难并行。
- 任务外置状态 ：
tasks/TASK-.../与board.md在版本控制中与其他代码 同仓演进，合并冲突以文本形式出现，可被工具与规范约束。
对多子系统 monorepo，这意味着：
- 中断后换人接手：读
TASK+STATUS即可恢复上下文，而不依赖上一任与模型的私聊记录。 - 并行开发：不同
TASK-...目录天然隔离「本轮叙事」，减少「两个 Agent 改同一篇巨型 TODO」的踩踏。
这与 harness 一致：每次试次有编号、有目录、有入口，而不是一锅粥。
附图四：任务生命周期（状态机）
与 tasks/README.md 一致；blocked / cancelled 未画全分支，主路径用于理解「何时允许宣称 done」。
外部依赖 / 风险
解除
需返工
draft
ready
in_progress
in_review
done
blocked
五、可回滚：协议层不替代 Git，但让「回滚什么」更清晰
回滚代码 ：Git revert / reset 仍是真相源。
Spec + Task 的价值 在于定义 回滚的语义单位：
- 若一次 PR 对应一个清晰
TASK-...，回滚时除代码外，可同步 revert 任务制品与 board 条目，避免「代码回去了、文档与 board 仍宣称已交付」的幽灵状态。 - 若采用分支-per-task 的工作方式，任务目录随分支走，合并即 把协议层产物一并合入 ，历史图谱上 代码与 TASK 叙事同一次提交或可追溯链。
这不是新工具链，而是 约定「任务束」与「合并单元」对齐，降低回滚后的认知负担。
附图五：回滚语义（Git 与任务束对齐）
任务束（协议真相源）
Git（代码真相源）
一次 PR / merge commit
git revert
或等价恢复
tasks/TASK-.../
整目录随分支演进
tasks/board.md
对应行状态
理想约定：
回滚代码时同步处理
board + 必要时 REVIEW
避免幽灵已交付
六、标准化：少写教程，多写「路由表 + 完成门」
可复制、低教程味的标准化，建议只抓三件事（与 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项目