Project Learning Loop
把项目交付、用户学习和证据积累视为同一个闭环。目标不是让代码尽快变多，而是让用户知道为什么做、
项目真正证明了什么、下一步为什么值得做。
默认执行纪律：完整检查，分层输出
本 Skill 的完整流程是内部检查表，不是每次回复都要展示的目录。面对一个新的复杂项目，首轮默认只输出：
- 核心判断：最多三句话说明当前真正的问题；
- 项目主线：用
目标 → 输入 → 处理 → 输出 → 验证给出一张短地图； - 当前阶段：只展开现在必须理解或决定的内容；
- 下一动作：一个可执行动作及其通过条件；
- 后续路线：最多给出阶段名，不提前灌输细节。
不要在首轮同时展开完整行业综述、五级门禁、全部实验模板和长期路线。完整性来自内部检查和可恢复的状态入口，
不是一次性把所有信息写给用户。
首轮默认控制在约 600～900 个中文字或等量信息内；用户明确要求完整方案、正式报告或充分细节时再放宽。
上述五项不必各建一个章节，能合并成短段落就合并。当前处于理解门时，只展开资产盘点及其通过条件；主流调研、
实验设计和后续门禁各用一句导航即可，不提前填写比较表、完整实验卡或证据清单。需要更多信息时，分轮继续，
不要以“以后可能用到”为由一次给全。
每轮教学默认只引入一个核心概念，最多带两个必要的依赖概念、一个具体例子和一个理解检查。用户说没跟上时，
先指出理解断点并缩小到输入/输出例子；不要把上一段换词后完整重讲。只有当前决策确实需要或用户主动要求时，
才展开下一层。
与其他工作流的边界
- 本 Skill 管理复杂项目从理解、调研、实验到阶段验收的协作方式。
- 文档或代码同步类 Skill（若可用）负责里程碑后的文档与代码同步；它不能替代前期调研、教学和实验门禁。
- 增量更新类 Skill（若可用）可辅助表达，但本 Skill 自身已经要求多轮协作默认只报告变化。
- 对单个明确小改动按正常工程流程处理，不要强行建立完整研究体系。
核心原则
1. 参考不是路线
外部仓库、前任脚本和竞品实现都只是候选证据。先标明来源与所有权，再判断其目标、年代、约束、
验证方式和已知缺陷。不要把“别人这样写”当作采用理由，也不要把参考目录写进自研演进历史。
2. 理解不能靠术语堆积
根据用户已经表现出的理解校准解释，不要求用户先自报水平。每个新概念按以下顺序展开：
- 它解决什么真实问题；
- 一个最小、具体的例子；
- 它在完整数据流或系统中的位置；
- 它对应哪些代码或配置；
- 用什么结果判断理解或实现是否正确。
除非用户明确想深入，不要从复杂入口文件逐行开讲。一次只引入完成当前决策所需的概念。
3. 能运行不等于有效
始终分开四种状态：
已实现：代码或配置存在；已运行：在明确环境中执行过；已验证：通过与目标匹配的测试或评测；可进入下一阶段：达到预先写明的门槛。
训练完成、接口返回 200、页面能打开、测试文件存在，都不能自动升级为下一种状态。
4. 多轮协作只报告增量
已有背景放在项目状态入口，后续默认只说明本次新增结论、实际变化、新证据、风险和下一项决定。
需求调整时先说清楚哪个假设、实验或验收标准被改变，不要重述整个历史。
启动流程
第一步：建立项目地图
在读深层代码前先查清：
- 用户真正要获得的能力和非目标；
- 哪些目录是自研、外部参考、归档、产品线、研究线或交付包；
- 当前事实来源：代码、运行环境、数据报告、日志、文档或口头描述；
- 已知阶段、当前阻塞和不可逆风险；
- 用户想学会什么，而不只是想拿到什么文件。
对已有仓库先做只读盘点。若用户只要求分析或复盘，不擅自修改文件。需要持久化且用户已授权修改时，
优先使用现有状态文档；没有合适入口时再建立一个短的 PROJECT_STATUS.md。模板见
references/artifacts.md。
项目地图至少要显式区分：事实 / 推断 / 方案 / 待验证。
第二步：建立主流基线
在采用架构、训练方法、框架或安全策略前，先回答：
- 当前问题有哪些主要解法家族？
- 每个家族优化什么，牺牲什么？
- 现有参考实现属于哪个家族，缺了什么？
- 在用户的算力、时间、合规和学习目标下，为什么选择当前路线？
- 什么证据会让我们改变路线？
可能随时间变化、用户明确要求“主流/最新”、或准确性影响重大时必须检索。技术调研优先论文、官方文档、
官方模型卡和官方仓库；二手文章只用来发现线索。不要为了显得全面罗列大量项目，选择能代表关键取舍的
最小集合。未经检索核实，不得凭记忆声称某个项目、版本或结果代表“当前主流”；无法联网时要明确说当前性
尚未核实，只把方法家族作为待验证候选。详细协议见
references/baseline-research.md。
第三步：给用户一张认知地图
先给出一页内能看懂的主线，再进入实现：
目标 → 输入 → 关键处理 → 输出 → 如何判断成功
为阅读代码安排由浅入深的顺序，并解释每个文件在主线中的职责。区分“现在必须理解”和“以后再学”。
用户表示没跟上时，缩小例子和概念跨度；不要仅仅换一种长篇说法重复一次。
认知地图不是课程大纲。首轮只展开地图上当前所在的一个节点，其余节点保留为导航。
第四步：把工作拆成可证伪实验
每个重要改动前写一张最小实验卡：
- 问题与假设；
- 为什么现在做；
- 只改变什么、保持什么不变；
- 数据与来源；
- 对照基线；
- 成功指标和最低门槛；
- 失败时如何解释或回退；
- 必须保存的命令、日志、配置、哈希和产物。
避免“先跑起来再看”。如果无法写出成功门槛，说明问题还没有定义清楚。
第五步：按门禁推进
复杂项目至少经过以下门禁；可按项目裁剪，但不能把后一个门禁偷换成前一个：
| 门禁 | 要回答的问题 | 典型证据 |
|---|---|---|
| 理解门 | 我们是否说清目标、边界和数据流？ | 项目地图、最小例子、用户关键疑问已解决 |
| 工程门 | 它是否可复现地运行？ | 环境、命令、版本、测试、日志、产物哈希 |
| 数据门 | 数据与划分是否可信？ | 来源、去重、泄漏检查、标签质量、覆盖度 |
| 研究门 | 它是否真的优于合理基线？ | 独立评测、误差切片、置信区间、消融或对照 |
| 产品门 | 它是否能在真实约束下安全运行？ | 契约、延迟、容量、失败模式、回滚、监控 |
评测集参与过选模、调参、阈值选择或教师生成时，不能称为独立最终测试。高分必须同时检查数据泄漏、
类别支持数、误报、漏报和对照质量。
第六步：维持精简项目状态
每个实质变化完成后更新一个短入口，而不是把历史复制到多个 README/design：
- 当前目标与边界；
- 当前候选或版本；
- 已验证事实；
- 未通过门槛；
- 下一项决定；
- 一行变更记录。
操作说明仍归 README/runbook，机制归 architecture/design，长期 AI 规则归 AGENTS/CLAUDE。不要让状态页
膨胀成全过程日记；详细实验结果链接到独立报告。
多轮回复格式
正在持续推进时，默认使用下面五项中的必要部分，不重复背景：
结论：本轮最重要的新判断。
本次变化：只列实际改变的代码、数据、配置或计划。
证据：测试、指标、日志、来源或尚未获得的证据。
风险/未知：会影响决策的内容，不列泛泛提醒。
下一步：一个明确动作，以及它通过什么门槛。
如果用户要求完整复盘，再提供完整版本。不要把中间工具过程当成果汇报。
新项目的首轮也要留下一个可恢复的短快照，但不必立即创建文件：当前阶段 / 已知事实 / 未验证假设 /
下一动作 / 通过条件。只有长期项目且用户已授权写入时，才把它落到状态文档。
反偏航检查
出现以下任一信号时暂停继续堆代码，先重新对齐：
- 用户说跟不上、看不懂或不知道为什么做；
- 需求多次改变但没有指出被推翻的假设；
- 同一背景被重复解释；
- 首轮回复已经像完整教程，用户却还不知道眼下只做什么；
- 外部参考与自研代码混为一谈；
- README、设计、运行环境和真实代码互相冲突；
- 只有训练/运行日志，没有独立评价；
- 文件或版本名称暗示的契约与实际内容不一致；
- 产品化范围扩大，但核心能力仍未通过研究门。
处理顺序：收集事实 → 标出矛盾 → 缩小当前问题 → 更新门槛 → 再决定是否实现。
阶段复盘与 Skill 持续改进
在项目里程碑、用户表达不满或流程重复失败时，做一次短复盘：
- 哪个可观察行为造成了返工或理解断层？
- 当时缺少哪条信息、门禁或解释？
- 这是单项目偶发问题，还是可迁移模式？
- 对本 Skill 的最小修改是什么？
- 哪个新测试用例能防止回归？
只有可迁移模式才进入 Skill。项目专属路径、模型名和一次性事故留在项目文档。修改 Skill 时使用
skill-creator 流程：更新版本和 CHANGELOG.md，补充或修改 evals/evals.json，
做有 Skill/无 Skill 对照，再决定是否保留变化。完整维护规范见
references/continuous-improvement.md。
完成标准
一次使用本 Skill 的结果应让用户能够回答：
- 我们在解决什么，暂时不解决什么？
- 为什么没有直接照搬参考实现？
- 当前方法与主要替代方案相比为什么合理？
- 我至少理解了下一步所需的核心概念吗？
- 当前究竟是已实现、已运行、已验证，还是已过门禁？
- 本次究竟改变了什么，下一次从哪里继续？
- 我现在是否只需要做一个明确动作，而不是消化整套项目生命周期？
如果这些问题仍需翻阅整段聊天才能回答，协作闭环还没有完成。
