将上一篇的痛点交给了AI来回答，以下内容答案由Gemini3 Pro提供：

1. 验证逻辑的“隔离与寄存”（针对痛点 1 & 2）
   痛点： 验证代码（如马氏距离检验）不属于主线，但必须存在。放在主 Context 中会挤占显存，导致主任务变笨；不放又无法验证。 Kiro 解决方案：多规范文件（Multiple Specs）与“影子工程” 不要试图在一个 requirements.md 里写完所有东西。Kiro 支持在同一个项目中存在多个 Spec 文件。

操作策略：

主线 Spec (.kiro/specs/main_analysis.md)： 只包含核心分析逻辑（数据加载 -> 建模 -> 结果）。

支线 Spec (.kiro/specs/verification_mahalanobis.md)： 专门用于验证。

执行流： 当你完成主线分析后，切换到验证 Spec。告诉 Kiro：“基于当前生成的数据，执行 verification_mahalanobis.md 中的任务”。

优势： 这种物理隔离确保了主线 Context 不会被验证逻辑污染，同时验证逻辑可以被复用和独立迭代。

2. 交互式“头脑风暴”与任务拆解（针对痛点 2 & 6）
   痛点： 需要 AI 像填空题一样引导用户发现未知的验证点，而不是一次性生成。 Kiro 解决方案：利用 Spec 生成阶段的“采访模式” Kiro 在生成 requirements.md 之前，会进行一轮需求分析。你可以强制它进入“苏格拉底式提问”模式。

操作策略（Steering Hack）：

在 .kiro/steering/interaction.md 中写入规则：

“在生成 requirements.md 之前，必须先列出至少 3 个潜在的统计学陷阱（如数据泄露、分布偏移），并询问用户是否需要针对这些点添加验证步骤。禁止直接生成代码，必须等待用户确认每一个验证点。”

效果： 这迫使 AI 从“执行者”变成“咨询顾问”，强行插入一个“确认环节”，解决了用户无法全面考虑验证影响的问题。

3. 统计严谨性的“宪法级”约束（针对痛点 3）
   痛点： AI 图省事用简便算法（如简便置换检验），导致结论不可靠。 Kiro 解决方案：Steering 文件的否定式约束（Negative Constraints） AI 很容易忽略“建议”，但很难忽略“禁止”。

操作策略：

在 .kiro/steering/tech.md 或专门的 statistics_rules.md 中写入：

"CRITICAL RULES:

禁止使用简便置换检验（permutation of statistics only）。所有置换检验必须执行完整的 ‘refit model on shuffled labels’ 流程。

涉及 p 值计算时，必须显式声明使用的零假设分布来源。

代码中凡是涉及随机性的地方，必须显式设置 seed，且该 seed 必须在配置文件的顶部定义。"

价值： 这相当于把你的科学哲学固化为代码审查规则，AI 每次生成代码前都会被这些规则“洗脑”。

4. 过程文件的“垃圾分类”与试错管理（针对痛点 4）
   痛点： 试错产生的中间文件污染目录，甚至被误读为最终结果。 Kiro 解决方案：结构化沙盒（Sandbox Enforcement） 利用 structure.md 强制文件分区。

操作策略：

在 .kiro/steering/structure.md 中规定：

“所有探索性分析和临时图表必须保存到 ./scratch/ 目录下，并以 YYYYMMDD_experiment_name 命名。禁止在 ./results/ 目录中保存任何未经 final_ 标签确认的文件。”

配合 Hooks： 设置一个 Agent Hook，当文件被保存到 ./results/ 时，自动触发一个检查脚本，确认该文件是否由经过验证的 pipeline 生成（例如检查是否有对应的 git commit hash）。

5. 存量代码的标准化重构（针对痛点 5）
   痛点： 面对一堆杂乱的旧代码，如何让 AI “哄”着用户去整理？ Kiro 解决方案：反向 Spec 生成（Reverse Spec Generation） Kiro 具有读取现有代码并反向生成 Spec 的能力 。

操作策略：

命令 Kiro：“读取 ./legacy_scripts/ 下的所有文件，理解其意图，然后生成一份 refactor_plan.md。不要直接重构，先列出你发现的逻辑断点和命名混乱处，并向我提问确认。”

这将启动一个交互式清理过程，AI 会像考古学家一样帮你梳理旧代码的脉络，而不是盲目重写。

6. 批判性审查与 Storyline 调整（针对痛点 7）
   痛点： AI 过于顺从，不敢指出“你的故事线有漏洞”。 Kiro 解决方案：专门的“红队” Agent（Critic Persona） 你可以定义一个专门用于“找茬”的 Agent 角色。

操作策略：

创建一个 .kiro/steering/reviewer.md，内容如下：

“你是一个苛刻的期刊审稿人（Reviewer #2）。你的任务不是写代码，而是审查 design.md 和 analysis_plan.md。你必须指出：1. 缺乏敏感性分析的地方；2. 统计方法选择的潜在偏差；3. 结论是否过度解读（Overclaiming）。请用批判性的语气提出建议。”

在设计阶段结束时，显式调用：“@Reviewer 请审查我的实验设计。”

7. Checkpoints vs. Git：决策瘫痪的解药
   痛点： Checkpoint 和 Git 功能重叠，导致不知道该用哪个。 批判性区分：

Kiro Checkpoints 是“撤销键（Undo）”的高级版： 它是会话级的。当你正在进行一次高强度的 vibe coding（比如调试一个难缠的 bug），你尝试了 A 方案失败了，Checkpoint 让你瞬间回到尝试前的状态，连同 Context 一起回滚。这在 Git 中需要繁琐的 git reset/stash。它的作用域是“当前这次尝试”。

Git 是“存档点（Save）”： 它是项目级的。只有当你确认某次尝试成功，并且代码是可以运行的，才提交到 Git。

结论：

试错过程（Exploration）： 疯狂使用 Checkpoints。不要怕搞坏环境，一键回滚。

阶段性成果（Milestone）： 一旦 Checkpoint 确认代码跑通了，立刻 Commit 到 Git。

无需纠结： Checkpoint 是给你后悔用的，Git 是给别人（或未来的你）看结果用的。不要用 Git 来存那些 broken state。

总结建议： 在科研场景下，Spec (规范) 就是你的实验记录本 (Lab Notebook)。 不要把 Kiro 当作一个“自动写论文机”，而要把它配置成一个**“极其守规矩的实验助手”**。通过 Steering 文件把你的科学品味（Scientific Taste）和统计底线（Statistical Rigor）硬编码进去，这样你就可以在享受 Vibe Coding 速度的同时，不丢失科学研究的严谨性。

---

以下是我对目前主流的一些AI功能概念应用的个人心得：
git 在当今的时代我看到了被取代的可能，目前比较刚需的还是进行跨会话级的版本控制，branch功能可能稍显鸡肋了，commit最后就是负责开源的一个小工具，在科研中还需配上.gitignore。
checkpoints 负责对话内的小型试错，稍显鸡肋。
hooks 用于给spec套上细节的trigger, 即生成spec应当在科研战略上利用AI的博学进行头脑风暴。而当细节牵一发而动全身的时候，还需要另一个hooks来做为spec更新器。
subagents，应当spec内负责并行任务（如果需要的话），则不应用来构建分支假设。
spec将可能大部分的替代git的功能——构建分支假设和旁支验证。
steering 负责项目全局的一些general mindset，比如批判性，战略性，交流语言等。
mcp则负责复杂模态数据的提取。

希望对AI4S的工程学最佳实践贡献一点心得，欢迎交流