【AI Native开发-05】技术不确定时，为什么不该让 AI 直接开写？

flowchart TD
    A["遇到一个不知道"] --> B{"答案由谁决定？"}
    B -- "业务取舍" --> C["需求不确定"]
    C --> D["讨论与决策 → 回写 Spec"]
    B -- "技术事实" --> E{"读代码 / 文档能确认吗？"}
    E -- "能" --> F["上下文检索 → 记录证据"]
    E -- "不能" --> G["限时 Spike"]
    G --> H["结论与证据 → 回写 Spec / Plan"]
    D --> I["重新过闸门"]
    F --> I
    H --> I

需求不确定：
  “删除之后要不要能恢复？”“普通作者能不能删自己的稿？”
  → 这是产品决策问题，答案在业务侧，靠问、靠讨论、靠取舍。
  → 产物：Spec 里的一条业务规则或非目标。

技术不确定：
  “这个 CMS 有没有提供删除接口？”“静态部署下删除操作发生在哪？”
  “第三方限流会不会让幂等重试失效？”
  → 这是事实问题，答案在代码、文档、运行结果里，靠做实验拿证据。
  → 产物：一份 Spike 结论。

人类工程师遇到不确定的 API：
  写不出来 → 去查文档 / 做个 demo → 确认后再写
  （不确定会自然阻塞动作）

AI 遇到不确定的 API：
  基于训练数据里“这类系统通常怎么设计”生成一整套实现
  → 代码结构完整、类型正确、测试可能还过
  → 但前提（那个接口存在 / 那个字段叫这个名）是错的
  （不确定不会阻塞动作，反而被流畅地掩盖）

差的 Spike 目标：“验证删除功能能不能做”
  → 太大，会一路发散成半个实现

好的 Spike 目标：
  “验证在 Keystatic local 存储 + 静态部署下，
   是否存在运行时删除接口；如果没有，删除的正确落点是什么。”
  → 单一、可回答、有明确的“答出来了”判据

模糊判据：“看看删除好不好做”
可判定判据：
- 若存在运行时删除接口：给出接口名称、调用方式、权限机制 → 结论=走接口
- 若不存在：确认删除=本地删除文件+Git 提交 → 结论=走本地文件操作，
  并列出这对“二次确认 / 权限”意味着什么

// keystatic.config.ts
storage: { kind: 'local' },
// 注释原文：EdgeOne Pages 是静态托管，不支持 SSR
// Keystatic 只能在本地开发时使用，编辑后 git push 触发自动部署

# Spike: 删除功能在静态架构中的落点
时间盒：半天
待回答问题：
  当前 Keystatic local + 静态部署下，删除文章应在哪一层完成？

已核实的仓库事实：
1. keystatic.config.ts：storage.kind = 'local'
2. astro.config.mjs：output = 'static'，当前未配置 SSR adapter
3. package.json：有 build / dev:cms 脚本，没有运行时删除 API 或测试脚本

由配置可以直接得出的结论：
- 当前生产部署没有承接在线删除请求的服务端
- 内容变更应落在本地内容工作流，而不是给静态站虚构在线 REST API
- 第 04 篇假想全栈案例中的 401/403/409 契约不适用于当前静态部署

仍需操作验证、不能靠配置假装已证实的事项：
1. 在临时分支用一篇测试文章执行 Keystatic 删除
2. 记录文件 Diff、必要的本机请求、Git 状态和构建结果
3. 核实谁可操作本地 CMS、谁有仓库写权限；二者不能默认画等号
4. 将命令、输出与结论写入正式 Spike 报告

开 Spike 的信号：
[ ] Spec / Plan 里有一条关键假设，无法靠读现有代码确认
[ ] 要依赖的 API / 第三方行为没在项目里用过
[ ] 两个技术方案选型，性能 / 可行性差异未知
[ ] 旧系统某个行为没有文档，只能跑一下看
[ ] 不验证就写 Plan，Plan 的核心步骤建立在猜测上

不该开 Spike 的情况：
[ ] 读代码 / 读文档就能确定的事（那是上下文检索，不是 Spike）
[ ] 产品取舍问题（那是需求决策，回去找业务方）
[ ] 正式实现里顺手写个测试就能覆盖的事

[ ] 最初的那个问题被明确回答（是/否/选哪个，不能是“大概可以”）
[ ] 有可复现的证据：命令、输出、观察记录，而不是“我试了一下”
[ ] 结论已回写到它该去的地方：
      影响需求边界 → Spec
      影响技术方案 → Plan
      是会重复踩的坑 → pitfalls.md
[ ] 实验代码保持一次性（已删除 / 留在独立分支 / 在临时目录）；
    如需转为产品代码，已另走正式 Plan、评审与验证，未以 Spike 名义直接合入
[ ] 若问题仍未回答：如实记录“不确定仍在”，
    并升级为需要人决策的风险，而不是带着猜测进 Implement

        Spec 编写中 / Plan 编写中
                │
        发现技术不确定？
           ┌────┴────┐
          否          是
           │           │
           │      ┌────▼─────┐
           │      │  Spike   │ 时间盒、单一问题
           │      │ 拿证据   │ 代码一次性
           │      └────┬─────┘
           │      结论回写
           │   Spec / Plan / pitfalls
           └────┬────┘
                ▼
          闸门判定（Gate 1 / Gate 2）

# Spike: <一句话标题>

## 元信息
- 时间盒：<半天 / 一天，截止时间>
- 提出者：
- 关联 Spec / Plan：<链接或路径>

## 待回答问题（只能一个）
<用一句话写成可回答的问题>

## 成功判据（动手前写）
- 若 <结果 A>：结论是 <……>，意味着 <……>
- 若 <结果 B>：结论是 <……>，意味着 <……>

## 实验过程（代码一次性）
1. <做了什么、跑了什么命令>
2. <观察到什么，关键输出 / 截图 / 数据>
3. 

## 结论（永久，回写依据）
- 问题的答案：<明确结论>
- 证据：<可复现的命令与输出>
- 对 Spec 的影响：<需新增 / 修改的条款，或“无”>
- 对 Plan 的影响：<技术方案的选择，或“无”>
- 应沉淀到 pitfalls 的条目：<或“无”>

## 实验代码去向
<已删除 / 分支名 / 临时目录——确认未合入主干>

## 残留不确定（如有）
<Spike 没能回答的部分，升级为风险，注明需要谁决策>