Professional Screenwriter Skill Tests

唯一规范源：../governance/control-plane-contract.md。本测试目录验证结构、追溯、基线和门禁，不把机器通过冒充创作质量通过。

可执行入口

在 Skill 根目录运行：

python scripts/validate_skill.py .
python scripts/run_e2e.py
python scripts/validate_project.py tests/feature-project-fixture
python scripts/validate_project.py tests/vertical-project-fixture

路径：

~/.codex/skills/professional-screenwriter/tests/

本目录用于验证：

Professional Screenwriter Skill
是否能在真实但受控的创作条件下，
稳定地产出可写、可审、可追溯、可生产的项目文件。

它不是：

- 剧本好坏的唯一裁判；
- 用文件数量替代创作质量的官僚系统；
- 通过模板填空自动证明故事成立的机制；
- 客户、平台、法务、保险、顾问或发行方的最终验收；
- 用受版权保护作品、真实人物或客户机密做演示的素材库。

为什么需要测试

编剧 Skill 的失败方式通常不是“没有生成文字”。

更常见的是：

- 生成剧本，但主角没有可执行目标；
- 生成大纲，但事件只是“然后发生”；
- 生成 Bible，但剧本静默改写了事实；
- 生成钩子，但没有兑现；
- 生成付费点，但靠重复和拖延维持留存；
- 生成 AI/实拍交接包，但它引用了旧剧本；
- 生成权利表，但外部事实与可复用素材被混淆；
- 生成变更通知，但没有同步任何下游文件；
- 标注为“最终版”，却没有单一有效基线；
- 生成很多专业名词，却仍然无法让陌生协作者继续工作。

本目录通过受控夹具、验收标准、变更传播和对抗式审查，验证以下命题：

这个 Skill 不只是能写。

它还能：
定义；
追溯；
检查；
修订；
同步；
锁定；
交接；
并在出现矛盾时阻止错误继续流入生产或发布。

测试的核心不是“作品是否符合某一种审美”。

测试的核心是：

在既定目标、约束与格式下，
输出是否满足其声称承担的职责。

快速开始

运行一个最小测试

选择一个测试夹具：

feature-project-fixture/
vertical-project-fixture/

从该夹具的 input-brief.md 开始，按照 SKILL.md 的任务路由执行。

最低运行顺序：

1. 读取 input-brief.md
2. 创建或填写 project-manifest.md
3. 建立 Story Bible
4. 建立适用大纲或分集地图
5. 建立场景卡
6. 产出剧本样段或主源
7. 运行对抗式审查
8. 引入预设上游变更
9. 完成影响分析与下游同步
10. 产出生产交接样段
11. 按 expected-deliverables.md 验收
12. 写入 Test Run 记录

运行结果不应只回答：

“文件生成了吗？”

而应回答：

“这个项目是否有唯一入口？
当前故事事实是否一致？
结构是否由因果和选择推动？
人物是否按其已知信息行动？
上游变更是否同步到了所有依赖文件？
权利和生产限制是否阻止了危险或无效交付？
下一位协作者能否从当前基线继续工作？”

目录结构

tests/
├── README.md
├── expected-deliverables.md
│
├── feature-project-fixture/
│   ├── input-brief.md
│   ├── expected-project-manifest.md
│   ├── expected-story-bible.md
│   ├── expected-outline.md
│   ├── expected-scene-cards/
│   ├── expected-script.fountain
│   ├── expected-review-report.md
│   ├── expected-upstream-notices.md
│   ├── expected-change-log.md
│   └── expected-handoff.md
│
└── vertical-project-fixture/
    ├── input-brief.md
    ├── expected-project-manifest.md
    ├── expected-story-bible.md
    ├── expected-season-map.md
    ├── expected-episode-01.md
    ├── expected-paywall-map.md
    ├── expected-review-report.md
    ├── expected-upstream-notices.md
    ├── expected-change-log.md
    └── expected-handoff.md

若未来增加自动化或半自动化检查，可增加：

tests/
├── scripts/
│   ├── validate-structure.[[ext]]
│   ├── validate-ids.[[ext]]
│   ├── validate-links.[[ext]]
│   └── validate-baselines.[[ext]]
│
├── reports/
│   ├── test-run-[[RUN-ID]].md
│   └── regression-summary.md
│
├── fixtures/
│   ├── shared/
│   ├── feature/
│   ├── vertical/
│   ├── rewrite/
│   ├── change/
│   ├── rights/
│   └── handoff/
│
└── archive/
    └── superseded-fixtures/

不应在 tests/ 中保存真实客户项目、未发布剧本、受限素材、个人数据、真实案件材料、未授权影视文本、第三方音乐、图片或视频。

测试夹具必须原创、虚构、最小化且可公开审查。

关键文件

`expected-deliverables.md`

本目录的权威验收规范。

它定义：

- 每类交付物必须包含什么；
- 什么算 DONE；
- 哪些情况必须 FAIL；
- 哪些文件之间必须可追溯；
- 长片、竖屏短剧、场景重写、变更、权利和交接的端到端断言；
- P0/P1/P2 的阻断规则；
- 人工审查与自动检查的边界；
- Test Run 记录格式。

若本 README 与 expected-deliverables.md 冲突：

以 expected-deliverables.md 为准。

本 README 的职责是：

解释如何运行和维护测试。

expected-deliverables.md 的职责是：

定义什么结果算通过。

测试夹具

每个 fixture 是一个受控输入 + 可验证预期组合。

它不是“唯一正确剧本答案”。

它提供：

输入：
- 足够明确的项目 Brief；
- 格式、受众、时长、画幅、商业或制作约束；
- 故事发动机最小条件；
- 已知风险、研究问题、生产限制或权利限制；
- 预设变更事件；
- 预设对抗性缺陷。

预期：
- 必须出现的交付物类别；
- 必须可追溯的事实和依赖；
- 必须识别的失败模式；
- 必须完成的同步动作；
- 允许存在的多种创作解法；
- 不可接受的输出类型。

第一性原理

测试的最小单位

对于此 Skill，最小测试单位不是一句台词、一页剧本或一份模板。

最小有效测试单位是：

一个可追溯的创作决策。

例如：

项目约束：
只能使用 9:16 画幅，单集 90 秒，第 8 集有付费点。

故事决策：
女主必须在第 8 集前选择公开证据，否则失去孩子抚养权。

结构决策：
第 8 集结尾证据被对手夺走，形成付费点；
第 9 集前 20 秒必须兑现“证据是否还存在”的承诺。

生产决策：
证据是一段手机录音，必须由声音、字幕和近景道具表达，
不能依赖横向远景或不可读小字 UI。

权利决策：
录音、界面、音乐、字体和品牌必须使用原创或已授权材料。

变更决策：
若真实平台 UI 不可使用，必须替换为虚构 UI，
并同步剧本、分镜、资产、字幕、生产包和 Change Log。

测试的任务是检查：

这些决策是否在每一层都保持一致。

测试不验证什么

本测试不宣称能够客观验证：

- 是否必然爆款；
- 是否必然获奖；
- 是否人人喜欢；
- 是否自动合法、可发行或无风险；
- 是否替代专业法律、医学、安全、工程、金融、文化或平台审查；
- 是否把复杂审美判断压缩成单一数字。

测试能验证的是：

- 项目约束是否明确；
- 输出是否覆盖必要职责；
- 事实与版本是否可追溯；
- 已知问题是否被识别；
- 变更是否传播；
- 风险是否被显式处理；
- 交付物是否能被下一环节使用。

测试类型

Test ID	类型	核心问题	必须产物
E2E-FEATURE	长片端到端	能否从 Brief 推进至可交接长片基线？	Manifest、Bible、大纲、场景卡、剧本、审查、变更、交接
E2E-VERTICAL	竖屏短剧端到端	能否构建钩子、兑现、付费与 9:16 可读性？	Manifest、Bible、分集图、付费地图、单集、审查、交接
E2E-REWRITE	场景/对白重写	是否让台词成为行动并保持上下文一致？	场景诊断、场景卡、重写稿、影响判断
E2E-CHANGE	上游变更传播	关键变化是否被完整同步和复验？	Notice、受影响文件、复验、Change Log、Manifest
E2E-RIGHTS	权利与研究变化	是否区分事实来源与可用素材，并阻断高风险使用？	Source、TP/Asset、Notice、替换或阻断
E2E-HANDOFF	制作交接	锁定剧本是否能安全进入 AI/实拍/后期？	镜头、资产、声音、字幕、权利、版本交接
E2E-ADVERSARIAL	对抗式审查	是否能识别隐藏的故事、连续性、权利和生产缺陷？	Review Report、发现、严重性、修订与复验

测试前条件

运行任何测试前，确认：

建议输出路径：

tests/reports/[[RUN-ID]]/
├── inputs/
├── outputs/
├── review/
├── evidence/
└── test-run-[[RUN-ID]].md

示例：

tests/reports/RUN-2026-07-10-FEATURE-001/
├── inputs/
├── outputs/
├── review/
├── evidence/
└── test-run-RUN-2026-07-10-FEATURE-001.md

运行步骤

1. 固定输入

复制或读取 fixture 的 input-brief.md。

记录：

- 测试夹具名称；
- 输入版本；
- Skill 版本；
- 测试日期；
- 执行人；
- 输出目录；
- 是否允许外部研究；
- 是否允许 AI 生成；
- 是否含预埋缺陷；
- 成功门槛。

输入一旦被用于正式测试，不应静默更改。

若必须更改输入：

1. 创建新输入版本；
2. 说明变更原因；
3. 更新 Run ID；
4. 不覆盖旧测试结果；
5. 将旧结果标为 SUPERSEDED，而不是删除。

2. 路由任务

依据 SKILL.md 和项目类型选择工作流。

项目类型	必须读取/使用
长片	`film-series-format.md`、Story Bible、长片大纲、场景卡、Fountain、审查、交接
竖屏短剧	`short-drama-playbook.md`、`hook-paywall-engine.md`、竖屏单集模板、审查、9:16 交接
场景重写	场景卡、前后场接口、人物知识状态、对白重写示例、审查报告
权利/来源变化	`source-links.md`、`third-party-notices.md`、资产登记、Notice、Change Log
生产交接	锁定剧本、资产状态、镜头/声音/UI、`ai-production-handoff.md`

若无法确定路由：

测试状态 = BLOCKED

不得通过“直接生成完整剧本”绕过路由不确定性。

3. 产出最小完整链

按照项目类型产出对应交付物。

长片最小链

Manifest
→ Bible
→ 长片大纲
→ 关键场景卡
→ 剧本样段/主源
→ 审查报告
→ 上游变更通知
→ Change Log
→ 制作交接包

竖屏最小链

Manifest
→ Bible
→ 季级承诺
→ 分集问题图
→ 钩子/兑现/付费图
→ 单集大纲
→ 场景卡
→ 竖屏剧本样段
→ 审查报告
→ 上游变更通知
→ Change Log
→ 9:16 制作交接包

4. 注入变更

完成初始链后，向项目注入 fixture 预设的 L2、L3 或 L4 变更。

示例：

故事：
主角父亲从“失踪”变为“主动伪造死亡”。

结构：
第 8 集的付费点从身份揭示改为证据公开。

格式：
横屏长片改为 9:16 连续短剧。

生产：
室外追逐因预算和安全限制改为室内追证对抗。

权利：
原背景音乐无法取得商业同步授权。

研究：
一项关键医疗/法律/历史设定被更可靠来源推翻。

测试目标不是看系统能否“继续写”。

测试目标是看系统是否：

识别变更级别；
建立 Notice；
找出所有受影响下游；
同步事实、结构、剧本、资产和生产内容；
复验一致性；
更新 Change Log；
让 Manifest 指向新基线；
在未完成同步时正确阻断 `LOCKED` 或 `project_stage=RELEASE`。

5. 执行对抗式审查

使用：

templates/review-report.md
references/adversarial-review-rubric.md
expected-deliverables.md

审查不能由“创作意图”自动豁免。

例如：

作者说“反派故意神秘”
不等于
反派没有策略也没问题。

作者说“这是情绪化跳跃”
不等于
时间线、人物知识和道具连续性可以失效。

作者说“AI 可以补”
不等于
缺少权利、资产、镜头、声音或制作限制的记录可以通过。

6. 记录结果

在 expected-deliverables.md 的 Test Run 模板中填写：

- RUN ID；
- 夹具与输入版本；
- 交付物版本；
- 每个断言 PASS / FAIL / N/A；
- P0/P1/P2 发现；
- 证据路径；
- 预埋缺陷识别率；
- 最终结论；
- 后续修订；
- 复验结果；
- 批准或阻断状态。

7. 做回归测试

当发生以下任一变更时，应重新运行受影响测试：

- SKILL.md 路由规则变化；
- Story Bible、大纲、场景卡、剧本或交接模板字段变化；
- 参考文件中的规范主源变化；
- 变更级别、锁定规则或 P0/P1/P2 定义变化；
- 来源、权利、AI 或生产交接策略变化；
- README 说明与实际目录结构变化；
- 新增/删除文件或迁移路径；
- 发现先前测试遗漏的失败模式。

最小回归矩阵：

改动	至少重跑
长片结构、大纲或 Fountain 模板	E2E-FEATURE、E2E-REWRITE、E2E-ADVERSARIAL
竖屏、钩子或付费规则	E2E-VERTICAL、E2E-ADVERSARIAL、E2E-HANDOFF
治理、版本、Notice、Manifest	E2E-CHANGE、E2E-FEATURE、E2E-VERTICAL
来源、第三方许可、AI 权利规则	E2E-RIGHTS、E2E-HANDOFF
交接、资产、镜头、字幕或 AI 制作规则	E2E-HANDOFF、E2E-CHANGE
审查量表	E2E-ADVERSARIAL，并复审所有门禁条件
README/目录变化	结构检查 + 所有受路径影响的测试

验收原则

文件存在不等于通过

以下输出仍然失败：

有 project-manifest.md，
但它没有当前 Bible、剧本、锁定状态或负责人。

有 story-bible.md，
但主角没有目标，对手没有策略，规则没有成本。

有 outline.md，
但所有节点都可以用“然后”连接。

有 scene-card.md，
但没有目标、阻碍、转折、结尾状态或前后场接口。

有 screenplay.fountain，
但人物不断使用不该知道的信息。

有 review-report.md，
但内容只是“节奏可以更好”。

有 change-log.md，
但重大改动没有 Notice、影响范围或迁移记录。

有 handoff.md，
但它引用了旧剧本和旧资产。

有 LICENSES 文件，
但音乐、字体、图片、声音或 AI 输入没有可定位权利状态。

多种创作答案可以通过

测试不要求所有项目写成同一种故事。

下列差异允许存在：

- 具体类型、人物、设定和结局；
- 三幕、八序列、章节、分集或其他适合的结构语言；
- 对白风格、调性、节奏和美术方向；
- 主角是否成功、失败、妥协、牺牲或改变；
- 长片、剧集、短片、竖屏、动画、实拍或混合生产方式。

但无论风格如何，以下要求不可省略：

- 项目目标与约束可见；
- 关键事实有权威来源；
- 事件具备因果；
- 人物在压力下作出选择；
- 关键场景改变状态；
- 变更可以追溯与传播；
- 风险可以识别与阻断；
- 制作交接能引用当前基线。

Fixture 设计规则

必须具备的输入

一个合格 fixture 的 input-brief.md 必须提供：

必须避免的输入

Fixture 不得：

- 复制或改写受版权保护影视作品的剧情、人物、台词或世界；
- 使用真实案件、真实受害人、真实未成年人或敏感个人资料；
- 包含可识别客户、雇主、合作方、真实商业秘密或内部材料；
- 使用未授权剧本、截图、海报、歌曲、图片、新闻视频或社交内容；
- 故意提供互相矛盾却不标记为测试缺陷的输入；
- 把“写一个好故事”作为唯一要求；
- 只提供形式要求，不提供人物压力、风险或可测试问题。

预埋缺陷标准

预埋缺陷必须：

- 可被文本证据证实；
- 有明确严重度；
- 不依赖某一种审美偏好；
- 能够通过修订或风险处理解决；
- 分布在故事、信息、连续性、制作、权利和治理维度；
- 不应全部集中在一个文件；
- 能够测试跨文件追溯能力。

推荐每个 E2E fixture 至少包含：

维度	最少预埋缺陷
因果/结构	2
人物/信息	2
连续性	1
格式/钩子/受众	1
生产	1
权利/来源/AI	1
治理/版本/变更	1

状态与评分

测试结论

状态	含义	后续动作
PASS	所有必要断言通过，无未关闭 P0/P1	可作为回归基线
CONDITIONAL PASS	无 P0，存在已登记、可控且有截止日期的 P1/P2	限定范围内继续，必须复验
BLOCKED	缺关键输入、权利、研究、审批、基线或生产决策	停止进入下一门禁
FAIL	关键输出缺失、事实冲突、P0 未处理或追溯链断裂	修复后完整重跑受影响链路
NOT_APPLICABLE	确认不适用且有理由	记录理由，不得静默跳过

严重度

等级	含义	是否阻断
P0	会使故事、权利、安全、生产或发布基线无效的关键问题	是
P1	显著影响质量、一致性、成本、可行性或合规，但可修复	是，除非书面接受
P2	局部问题、可控优化或低风险不一致	否，但应排期修复
INFO	观察、建议或未来改进	否

通过门槛

以下均须满足：

1. 所有强制交付物存在且满足其验收标准；

2. 所有 P0 已修复；开发阶段接受的 P0 必须标记 `ACCEPTED_RISK`，不得进入生产或发布；

3. 所有 P1 已关闭，
   或存在明确的书面风险接受：
   - 接受人；
   - 后果；
   - 补偿措施；
   - 到期日；
   - 复审条件；

4. 当前 Manifest 指向唯一有效基线；

5. 所有 L2-L4 变更有 Notice 或明确无需 Notice 的记录；

6. 预埋 P0/P1 缺陷识别率达到 expected-deliverables.md 的门槛；

7. 对应 Change Log、权利记录、审查报告与生产交接已同步；

8. 新成员能够仅凭现有文件继续下一步，不依赖口头解释。

自动化与人工审查

适合自动检查的内容

可使用脚本、正则、链接检查或结构验证辅助检查：

- 文件和目录是否存在；
- Manifest 引用的文件路径是否存在；
- 必填字段、ID、版本、状态、日期和负责人是否缺失；
- ID 是否重复；
- Notice 是否列出前后状态和影响范围；
- Change Log 是否关联 Notice；
- Story Bible、场景卡和交接包是否引用必要 ID；
- LOCKED 文件是否仍有未关闭 P0；
- 交付目录是否包含草稿、批注、敏感路径或明显机密文件名；
- 许可证、NOTICE、署名和权利登记是否有引用位置。

必须人工判断的内容

以下问题无法仅用字段存在性证明：

- 因果是否成立；
- 人物是否真实地想要、害怕、选择和承担后果；
- 对手是否具备主动策略；
- 中点是否真正改变问题；
- 高潮是否由主角选择推动；
- 台词是否是行动而非解释；
- 钩子是否公平兑现；
- 竖屏信息是否在移动端真正可读；
- AI 输出是否近似受保护人物、品牌、风格或作品；
- 权利链、授权范围、合同与平台条款是否充分；
- 实拍风险、预算、资源、安全与排期是否真实可行。

原则：

自动化擅长发现“没有填”。

对抗式人工审查负责发现“填了，但仍然不成立”。

变更与回归

何时必须重跑

以下改动会影响系统行为，必须触发回归：

修改 SKILL.md 的任务路由、优先级、锁定或审查规则
修改 Story Bible、大纲、场景卡、剧本、竖屏单集或交接模板的字段
修改 adversarial-review-rubric.md
修改钩子、付费点、兑现或商业模型规则
修改来源、权利、许可证、第三方材料或 AI 风险规则
修改 Change Log、Notice、Manifest 或版本规则
修改目录路径、命名、模板引用或 README 导航
修改长片、剧集、竖屏、实拍或 AI 生产策略
修复了一个历史缺陷，且需要证明未引入新的矛盾

回归原则

修复一个缺陷后，
不要只验证“缺陷消失”。

还必须验证：

- 修复没有破坏上游事实；
- 修复没有造成下游文件过期；
- 修复没有引入新的连续性、权利或生产问题；
- 修复后的版本能仍通过原有关键断言；
- 旧测试结论没有被静默覆盖。

回归记录

每一次回归应记录：

- 变更版本；
- 触发原因；
- 受影响 fixture；
- 新增/修改断言；
- 旧结果；
- 新结果；
- 新发现问题；
- 是否更新 expected-deliverables.md；
- 是否更新 Change Log。

对抗式审查

在宣布“测试通过”之前，执行以下检查。

测试完整性检察官

这个 fixture 是否只测试了最容易成功的路径？
输入是否过于模糊，以至于任何输出都能自称合理？
预期结果是否具体到能被第三方判定？
是否把文件存在、字段填满或语言华丽误判为功能通过？
是否存在只由测试作者知道、但输入中没有写明的隐藏标准？
是否允许多种创作答案，同时仍严守因果、追溯、版本和风险门槛？

故事检察官

测试是否真的能发现主角被动、对手无策略、中点失效、高潮靠巧合的问题？
是否测试了人物信息不对称、秘密传播、误解和知识越权？
是否测试了场景是否改变状态？
是否测试了钩子与兑现，而不是只检查是否有 cliffhanger？
是否测试了主题是否在选择中被检验？
是否让“类型惯例”成为逃避因果的借口？

治理检察官

上游变更是否真的让下游文件改变，还是只创建了一张 Notice 表？
Manifest 是否在测试中实际承担基线入口作用？
Change Log 是否记录了已确认的变化，而不是复制任务列表？
锁定的文件是否仍有未关闭 P0？
是否能从任意关键镜头、场景或资产反向追溯到故事和项目约束？
是否有旧文件或旧资产被错误地当作当前版本？

权利检察官

测试是否区分“事实可引用”与“表达可复用”？
是否测试了音乐、字体、图像、品牌、真实人物、声音、地图、UI、代码和 AI 的不同权利层？
是否把“免费”“公版”“已购买”“AI 生成”错误当作自动通行？
权利变化是否会真正阻断发布并触发资产/脚本替换？
是否误把法律结论自动化或把内部登记当作授权证明？

生产检察官

测试是否检查交接包和锁定剧本版本一致？
竖屏测试是否检查真实可读性，而非仅写了“9:16”？
AI 测试是否检查输入、模型、角色锚点、声音、相似性和输出审阅？
实拍测试是否检查地点、动作、演员、安全、许可、预算和后期？
是否测试了已拍/已生成资产对故事变更的反向压力？
是否允许“后期再解决”成为未记录问题的避难所？

维护规则

修改测试时

对 expected-deliverables.md、fixture 或测试规则的修改必须：

新增 fixture 时

每个新 fixture 至少应包含：

- input-brief.md；
- 适用的 expected deliverables；
- 可追溯的约束、假设、风险和成功标准；
- 至少一个故事/结构缺陷；
- 至少一个信息/连续性缺陷；
- 至少一个生产或格式限制；
- 至少一个来源、权利或 AI 风险；
- 至少一个 L2-L4 上游变更；
- 预期对抗审查发现；
- 明确的通过/失败门槛。

测试运行模板

每次测试可使用以下最小记录：

# Test Run: [[RUN-ID]]

| 字段 | 内容 |
|---|---|
| 日期 | [[YYYY-MM-DD]] |
| Skill 版本 | |
| Fixture | |
| 输入版本 | |
| 执行人 | |
| 审查人 | |
| 输出路径 | |
| 测试类型 | E2E-FEATURE / E2E-VERTICAL / E2E-REWRITE / E2E-CHANGE / E2E-RIGHTS / E2E-HANDOFF / E2E-ADVERSARIAL |
| 总体结论 | PASS / CONDITIONAL PASS / BLOCKED / FAIL |
| P0 | |
| P1 | |
| P2 | |
| 预埋 P0/P1 | |
| 已识别 P0/P1 | |
| 识别率 | |
| 关联 Change Log | |

## 关键断言

| ID | 断言 | 状态 | 证据 | 备注 |
|---|---|---|---|---|
| | | PASS / FAIL / N/A | | |

## 发现

| Finding ID | 等级 | 问题 | 位置 | 修订动作 | 负责人 | 截止 | 复验 |
|---|---|---|---|---|---|---|---|
| | P0 / P1 / P2 | | | | | | |

## 最终决定

```text
[说明为什么通过、条件通过、阻断或失败；
说明允许进入什么阶段；
说明禁止进入什么阶段；
说明必须完成的后续动作。]


完整字段与专属验收条件以：

```text
tests/expected-deliverables.md

为准。

最终原则

测试不是为了把创作变成流水线。

测试是为了防止创作在复杂协作中失去：

事实；
因果；
人物选择；
信息边界；
连续性；
版本控制；
权利边界；
生产可行性；
以及对观众承诺的兑现。

一个真正通过测试的编剧 Skill，
不一定写出唯一正确的故事。

但它应当能持续避免那些可预见、可追溯、
却常被“灵感”“赶工”“版本混乱”或“AI 可以补救”
掩盖的系统性失败。

FilesExpand file tree

testing-guide.md

Latest commit

History