五个方向，挑一个开玩

今天想让 AI 多接一点什么活：顺着报错找任务，自己试几轮实验，还是收工后整理经验？先看表格，挑一个最想亲眼验证的方向，展开它的小实验。

想先看实际案例，可以打开已落地的 AI 开发实践。其中收录了 CodeRabbit 等六项方案，也有下文故障驱动方向的使用记录。

这五个方向补充“人提交 Issue → AI 修复”和“独立 AI 审查”。它们分别改变任务从哪里来、如何寻找解法、在哪里验收、怎样表达意图，以及经验如何复用。

资料核对：2026-10-21。最近两个月的检索窗口是 2026-08-21—2026-10-21。下表列的是代表方案的公开时间或更新节点；规格、模拟和实验优化本身有更早的历史。每节的“借到自己的项目里”和“小实验”是本次脑暴建议，尚未实际接入或运行。

方向	代表方案与时间证据	现有证据到哪一步
1. 让真实故障发起任务	Seer：2025-06-17 正式发布；Seer Agent：2026-09-29 增强	已有调试产品；近期增强仍以发布文章描述的能力与状态为准
2. 给目标，让 AI 自动做实验	Karpathy autoresearch：2026-03，README 自述	公开的模型训练实验项目，迁移到 Web 开发需另建评估
3. 在模拟世界里先造一遍	StrongDM Software Factory：2026-02-06 工程文章	公司实践自述，不能推成所有项目的成熟方案
4. 把意图写成长期规格	GitHub Spec Kit：2025-09-02 发布文章	开源工具与明确工作流，具体项目收益需验证
5. 让 AI 下班后整理知识	Letta Sleep-time Compute：2025-04-21 研究发布	研究与框架实现，编码项目的收益仍要单独测量

1. 让真实故障发起任务

你负责决定什么体验值得修，运行数据帮助 AI 发现具体问题。

展开来源、接法和一个小实验

已有事实。 Sentry 在 2025-06-17 发布的 Seer 功能包括结合堆栈、追踪和代码分析根因、建议修复，以及自动创建 PR。正式发布说明

2026-09-29 的 Seer Agent 更新加入 Sentry API 写操作，以及来自 Datadog、Google Cloud Platform 等平台的诊断数据连接；该文章当时将 Seer Agent 标为 beta。这是近期增强，不能把整个“AI 调试”的诞生日期写成 2026 年 9 月。近期更新原文

借到自己的项目里。 一个页面反复报错，先按错误类型与版本归并，再让 AI 把运行证据整理成候选 Issue。你确认优先级后，交给现有夜班流程：

错误事件与版本 → 归并去重 → 根因假设与复现线索
              → 候选 Issue → 你选择 → 补丁与验证

小实验。 选三份已脱敏的本地错误记录，让 AI 判断是同一个 bug 还是三个不同问题，并给出证据。先只生成报告。

交付与边界。 应留下错误样本、受影响版本、推断依据和待确认项。日志缺失、用户数据处理与错误归因都可能影响结果；这里先生成可审阅任务，正式环境的修改与发布另外决定。

2. 给目标，让 AI 自动做实验

你给一个可以测量的目标，AI 尝试不同改法，保留有证据的改进。

展开来源、接法和一个小实验

已有事实。 Karpathy 的 autoresearch README 将项目置于 2026 年 3 月：Agent 修改训练代码，在固定的五分钟训练预算下比较验证指标，再保留或放弃改动。原项目围绕单 GPU 模型训练，评估与可修改代码有明确分工；这里没有将它描述成通用 Web 优化工具，也未认定具体首发日。项目 README

借到自己的项目里。 你提出“让固定样本的处理更快，输出保持一致”，让 AI 自动寻找方案：

固定输入与评估 → 测基线 → 修改一个实现 → 检查输出与耗时
              → 保留改善或放弃 → 留下实验记录

小实验。 选择一个纯函数，固定输入、输出判定和测量方式，让 AI 最多尝试三种实现。保留每种方案的代码版本和多次测量结果，先比较报告，再选择采用哪一种。

交付与边界。 实验记录要包含失败方案、预算和测量环境。评估脚本应由独立步骤保管；加速不能通过删掉正确性检查或更换输入实现。这个实验验证的是特定工作负载，不能据此推断整个应用更流畅。

3. 在模拟世界里先造一遍

先给 AI 一套能反复尝试的假接口和真实使用场景，再让它生成与修正代码。

展开来源、接法和一个小实验

已有事实。 StrongDM 在 2026-02-06 介绍了 Software Factory：用规格和场景驱动开发，在第三方服务的行为克隆环境中验证。其 Digital Twin Universe 模拟了 Okta、Jira、Slack 等服务的 API、边界与可观察行为；文章也描述了将部分验收场景放在代码仓库之外的做法。StrongDM 原文

这是该公司的工程实践自述。本文借用场景和仿真环境的思路，不将其自动收敛能力或经济收益视为独立验证结果。

借到自己的项目里。 给 Yuuki 的一个外部工具做最小模拟服务，让 AI 在其中实现与验收任务：

用户场景 → 最小模拟接口 → AI 构建工具调用
        → 正常与故障场景验收 → 复查真实接口差异

小实验。 只模拟“读取一个任务”的接口，准备成功、超时和重复响应三种情况。让 AI 实现调用和恢复路径，再用固定场景验收。

交付与边界。 保存模拟协议、场景输入和行为记录。模拟越偏离真实服务，结果越难迁移；通过模拟场景后，仍需在真实接口允许的测试环境中确认关键行为。

4. 把意图写成长期规格

你维护几条重要的产品规则，AI 根据规则更新计划、代码和验收。

展开来源、接法和一个小实验

已有事实。 GitHub 于 2025-09-02 介绍开源 Spec Kit，以 Specify、Plan、Tasks、Implement 的流程，让规格参与计划、任务划分与实现。它体现了用明确意图持续驱动 Agent 的做法；自然语言规格仍需要解释和验证，不能视为正确性证明。发布文章

借到自己的项目里。 为轻量模式保留三条短规格，后续每次改动都对照它们：

默认只展示专题入口。
切换到完整模式后，所有文档仍可找到。
刷新后保留选择；存储不可用时，本页仍能切换。

小实验。 请 AI 根据这三条规则列出验收场景，然后只实现其中一条小变更。你只需判断规格是否准确、改动是否满足规格。

交付与边界。 规格、实现和验收结果应能互相对应。发现产品规则不准确时，先明确修改规则，再据此调整代码；先用几行文字就能实验，不要求安装完整工具链或建立一套大流程。

5. 让 AI 下班后整理知识

夜间任务也可以只是读懂项目、整理经验，让下一次任务更容易开始。

展开来源、接法和一个小实验

已有事实。 Letta 于 2025-04-21 发布 Sleep-time Compute：利用用户不等待回答的时段处理已有上下文，形成可复用资料；实现中将主 Agent 与负责整理记忆的 Agent 分开。论文与文章报告的评估范围，不等于个人编码项目已经获得相同收益。研究与实现介绍

借到自己的项目里。 用已经接受的 PR、已确认的审查意见和失败记录，生成下次任务可查的三条候选经验：

已验证的任务记录 → 找出重复问题 → 候选规则与证据链接
                → 你确认 → 版本化保存 → 下次按需读取

小实验。 只提供一份已经完成的 PR，让 AI 提取“改动了什么、踩过什么坑、下次怎样确认”，每项一句话，并附原始依据。先停在候选文档。

交付与边界。 每条经验需要来源、适用范围和失效条件；过时规则可以撤回。整理的是外部上下文与资料，不是重新训练模型。把候选经验采纳为长期规则需要你的明确选择。

今天选哪一个

如果当前目标是减少验收与返工，先看你的工作流分析。如果想从本页挑一个探索实验，可以选 方向 4：把轻量模式写成三条规格，再核对一次实现，它不需要新账号或新服务。想尝试自动优化，则可以选方向 2，先固定正确性与测量方式。

这些是五种不同的探索入口。已有产品支持、公司实践和研究原型能说明可行路径；实际节省多少时间、减少多少错误，要用自己的任务记录判断。

返回整张构想地图或Issue 夜班入口。本文只新增教学与研究材料，尚未运行这些实验或启用相应自动化。