Task Contract + Rule + Skill + Harness
用四个相互分工的层次，把 AI 工作从临时对话变成可治理系统。
对应研究命题：AI 如何从一堆工具，变成真正可治理的工作系统？
一堆聊天窗口、一堆模型、一堆插件，还不等于系统。系统要回答四件事：这次要干什么、不能干什么、能力怎么复用、结果怎么验收。
本方法把这四件事拆成四层。它们可以一起用，但不要混成一层大提示词。
1. Task Contract（任务契约）
管什么：这一次任务的目标、范围、成功标准、禁止事项、交付物形态。
为什么单独一层：没有契约，模型和人都会“感觉做完了”，却对不齐验收。
最小写法（可写在对话开头、工单或 Session 里）：
- 要解决的问题（一句话）
- 算做成的样子（可观察，≤3 条）
- 明确不做的事
- 谁拍板、什么必须等人确认（例如公网发布、改全局规则）
不是：长篇背景故事、也不是工具清单。
2. Rule（规则 / 边界）
管什么：跨任务仍成立的约束——安全、隐私、口令路由、发布确认、命名与收尾习惯。
为什么单独一层：规则解决的是“再聪明也不能踩线”，不是“这一次怎么写得漂亮”。
真实工作中的形态举例（公开描述，不展开私密配置）：
- 全局与项目规则（何时能部署、何时必须停手）
- 决策门：真分叉归人，Agent 不代决
- 内容状态：
published/coming-soon/draft不得假装有证据
风险：规则越多，上下文越重，冲突越多。规则密度本身是另一条研究命题，本方法要求：能写成“触发条件 + 动作 + 禁止”的短合同，就不要写成散文。
3. Skill（可复用能力包）
管什么：某一类任务的固定做法——步骤、输入输出、检查清单、常用脚本入口。
为什么单独一层：Skill 是“会做某类事的说明书”，不是“永远正确的世界观”。
使用原则：
- 先有任务契约，再调用 Skill，避免拿错说明书
- Skill 与全局规则冲突时，以更高层合同为准（例如已提炼的协作协议优先于角色扮演式 skill）
- 同一 Skill 应能在不同任务上复用；复用失败时记入证据，而不是默默改提示词糊弄过去
4. Harness（执行与验收环境）
管什么：真正跑起来的环境——编辑器/Agent、预览端口、构建与审计命令、版本与备份、日志与回写位置。
为什么单独一层：没有 Harness，再好的方法也只停留在“聊过”。
本实验室当前公开可见的 Harness 片段：
- 实验室内容放在
content/lab/，用状态字段控制是否可点开 - 本地用构建与内容审计（
npm run validate）检查，而不是只靠肉眼 - 公网切换与正式本地入口切换，必须单独确认——方法层不授权发布
四层怎么串
Task Contract → 这一次要什么、不要什么
↓
Rule → 任何一次都不能破的边界
↓
Skill → 这类事按哪套步骤做
↓
Harness → 在哪执行、如何验证、如何留下记录串完之后，才谈“系统”，而不是“今天换了个更强的模型”。
适用边界
适合：重复出现的工作（报告、站点内容、多工具协作、有确认门的发布）。
不适合硬套：一次性探索闲聊、尚未形成验收标准的纯头脑风暴——那些可以先只有松散笔记，不必假装四层齐全。
和“证明系统”的关系
站点结构上的「研究 → 方法 → 实践 → 证据」是对外如何公开；
Task Contract + Rule + Skill + Harness 是对内如何干活。
两者应对齐：公开的方法页对应可复用的 Skill/Rule；公开的实践对应真实 Harness 中的版本；公开的证据对应验收与复盘，而不是营销话术。
当前版本说明
- 版本：
v0.2 - 状态：可公开阅读的工作方法，不是“已在所有场景证明最优”
- 下一环：实践现场 · 建立可治理的 AI 工作系统