Claude 4.8 刷屏全网，但90%开发者都看错了重点

短任务和长期任务不是一回事

  短任务一般长这样：

• 写一个函数。
• 解释一个报错。
• 改一段文案。
• 生成一个脚本。
• 帮你补一段测试。

  这类任务边界很小，错了也容易看出来。

  长期任务就不一样。

  比如你让 Agent 做这样一件事：

• 先读项目结构。
• 找出某个功能为什么报错。
• 判断应该改哪些文件。
• 修改代码。
• 跑测试或本地验证。
• 总结修改内容。
• 把这次结论写进项目文档。

  这已经不是“写代码”了。
  这是让 AI 接一个小型开发任务。

  任务一变长，风险也会变：

• 它可能忘记最初目标。
• 它可能顺手改了不该改的文件。
• 它可能为了修一个小问题，重构一大片。
• 它可能没跑验证就说完成了。
• 它可能做完以后没有留下任何记录，下次还要重新解释。

  所以，长期任务的核心不是一句更漂亮的 Prompt。
  它更像一份任务规格。

我会把 Prompt 升级成任务说明

  如果只是让 AI 帮你写一个函数，随口说一句也许够用。

  但如果让 Agent 接长期任务，我现在会先写一份 Agent Task Brief。

  它大概长这样：

# Agent Task Brief

## Goal
修复用户登录后偶发跳回登录页的问题，并给出原因说明。

## Context
- 项目：Next.js + Better Auth
- 重点查看：app/、lib/auth/、middleware.ts
- 先读 README.md 和 AGENTS.md

## Allowed Changes
- 可以修改登录状态判断相关代码
- 可以新增或修改测试
- 可以更新项目内文档

## Do Not Touch
- 不要修改 .env
- 不要改数据库 schema
- 不要改 CI/CD 配置
- 不要删除文件
- 不要直接发布或部署

## Checkpoints
1. 读完项目后，先总结你理解的问题，不要立刻改代码
2. 准备改文件前，先列出计划
3. 涉及 auth、middleware、数据库、环境变量时，先停下来确认
4. 改完后必须跑验证命令

## Validation
- npm test
- npm run lint
- 手动说明登录流程如何验证

## Writeback
- 在 docs/debug-log.md 记录：
- 问题原因
- 改了哪些文件
- 怎么验证
- 下次遇到类似问题先看哪里

  这份东西看起来很简单，但很有用。

  它解决的不是“AI 会不会写代码”。
  它解决的是：

• AI 能不能知道目标。
• AI 能不能知道边界。
• AI 能不能知道什么时候停。
• AI 能不能知道怎么证明自己做完了。
• AI 能不能把结果留下来。

  这才是长期任务里真正重要的部分。

Agent 最容易出问题的地方，不是不会写，而是越界

  很多人刚用 AI Coding Agent，会先被它的执行力震到。

  你让它修 bug，它能修。
  你让它补测试，它能补。
  你让它解释项目，它也能解释。

  但只要把它放进真实项目里跑几次，就会遇到另一个问题：

  它可能太主动了。

  比如：

• 你只是让它分析问题，它顺手开始改代码。
• 你只是让它改一个页面，它顺手重构了组件结构。
• 你只是让它跑验证，它觉得应该装一个新依赖。
• 你只是让它整理文档，它顺手改了旧入口。

  这不是 Agent 坏。
  这是任务边界没有写清楚。

  所以我会给长期任务设几条硬边界：

  这里的重点不是限制 AI。
  而是让它知道哪些地方可以自己推进，哪些地方必须把人拉回来。

  长期任务越复杂，越需要这种边界。

长期任务必须有检查点

  我以前也喜欢让 AI 一口气做完。
  后来发现，这种方式适合小任务，不适合长期任务。

  长期任务更合理的方式是分检查点。

  比如一个修 bug 任务，可以拆成这样：

阶段 1：读项目
- 输出项目结构理解
- 输出可能相关文件
- 不改代码

阶段 2：定位问题
- 输出问题假设
- 输出证据
- 输出准备修改的文件
- 等确认后再改

阶段 3：修改代码
- 只改确认过的文件
- 保持改动范围小
- 不顺手重构无关模块

阶段 4：验证
- 跑测试
- 跑 lint
- 说明手动验证步骤

阶段 5：回写
- 记录问题原因
- 记录改动文件
- 记录验证结果
- 记录下次排查入口

  这比一句“帮我修一下”麻烦一点。
  但它能明显减少跑偏。

  因为 Agent 每走一段，都要把当前理解亮出来。
  你也能及时发现它是不是理解错了。

第二大脑可以变成 Agent 的工作记忆

  如果 Agent 做完任务，结果只停留在聊天记录里，价值会少一半。
  因为下次你还要重新解释。

  长期任务真正有价值的地方，是它能沉淀成下一次的基础。

  比如每次任务结束，我希望留下这样的记录：

# Task Log

## What Changed
- 修复登录态判断逻辑
- 调整 middleware 中的 session 读取方式

## Why
- 登录后跳回登录页，是因为部分请求没有正确携带 session 状态

## Files
- middleware.ts
- lib/auth/session.ts
- docs/debug-log.md

## Validation
- npm test：通过
- npm run lint：通过
- 手动登录流程：通过

## Follow-up
- 如果下次出现登录态异常，先检查 middleware 和 session 读取逻辑
- 不要直接怀疑 OAuth 配置

  这就是我理解的第二大脑在 Agent 时代的变化。

  它不只是资料仓库。
  它会变成 Agent 的工作记忆。

  你把每次任务的目标、边界、修改、验证和经验留下来，下一次 Agent 就不是从零开始。
  它可以沿着你的系统继续干。

Claude、Codex、NLWeb 其实都指向同一个方向

  如果单独看 Claude Opus 4.8，它是模型更新。
  如果单独看 Codex，它是 AI 编程工具。
  如果单独看 NLWeb，它是让网站和 Agent 更好交互的方向。

  但放在一起看，它们其实都在指向同一件事：

  AI 正在从“给答案”，走向“进工作流”。

  Claude 这类模型更新，让 Agent 更能处理长任务。
  Codex 这类编程工具，让 Agent 更接近真实项目。
  NLWeb 这类方向，让网站、知识库、内容系统更容易被 Agent 理解。

  而第二大脑解决的是另一端：
  Agent 做完事以后，结果放哪里？规则怎么沉淀？下次怎么接着干？

  所以我不会只把 Claude Opus 4.8 看成一次“模型更强”的新闻。
  它更像是在提醒我们：

  开发者使用 AI 的方式要变了。

给 AI Coding Agent 派长期任务的清单

  最后给一份我现在会用的检查清单。

  下次你准备让 AI Coding Agent 接一个长期任务，可以先过一遍：

• 目标是否写清楚？
• 任务范围是否写清楚？
• 允许读哪些文件？
• 允许改哪些文件？
• 哪些文件和操作不能碰？
• 哪些动作必须先问人？
• 中间检查点是什么？
• 验证命令是什么？
• 如果验证失败，怎么处理？
• 最后结果写回哪里？

  这套东西不复杂。
  但它会把你从“和 AI 聊天”，推进到“管理 AI 干活”。

  这才是 Agent 能接长期任务后，开发者真正要补的一课。

总的来说

  Claude Opus 4.8 当然值得关注。

  但我不建议只盯着“模型是不是更强”。
  更值得看的，是 AI Coding Agent 的任务形态正在变化。

  它不只是回答一个问题。
  它开始能接一段工作。

  而长期任务一旦交给 Agent，开发者最该补的就不是更多花哨 Prompt，而是：

• 任务说明。
• 权限边界。
• 检查点。
• 验证方式。
• 结果回写。

  以后会用 AI 不够了。
  还要会安排 AI 干活。