说明：这篇文章来自我过去几年的真实经历。为了适合公开发布，部分公司、学校、求职信息、服务器信息和过细的个人细节做了脱敏。

我第一次用 ChatGPT，已经记不清是哪一天了。

能比较确定的是，2023 年刚上大学不久，我在做数学建模、学编程的时候，就已经开始频繁问它问题。

那时候我对 AI 的理解很简单。

不会的知识，问它。

代码写不出来，让它帮我写。

报错了，把报错贴进去。

如果当时有人问我 ChatGPT 是什么，我大概会说：

一个比搜索引擎更好用的答案机器。

几年以后再回头看，我发现真正发生变化的不是模型越来越强，而是我使用 AI 的方式完全变了。

现在我更关心的问题已经不是：

“它能不能回答这个问题？”

而是：

“怎么让 AI 在一个真实工程里长期、可靠地完成工作？”

这中间大概经历了几个阶段。

01｜最开始，AI 只是帮我把题做出来

2023 到 2024 年，我对 AI 的使用基本都围绕学习和比赛。

当时做过一些数学建模项目，要处理数据、写 Python、设计模型、解释结果。

ChatGPT 在里面很有用。

但它的角色始终在我旁边。

流程大概是：

我理解问题
↓
我决定怎么做
↓
ChatGPT 帮我分析 / 写代码
↓
我把结果拼起来

这一阶段真正留下来的，其实不是某个 Prompt。

而是一种做事方式：

现实问题 → 抽象 → 写程序 → 看结果 → 再验证。

后来我做 Agent、做业务系统、做 FDE，底层还是这套逻辑。

只是问题越来越真实，系统越来越大。

02｜第一次意识到：AI 可以直接产生生产力

后来我去一家软件公司实习。

工作里有不少重复的数据处理任务：字段映射、格式转换、批量重命名、数据检查。

一开始就是人工做。

做多了以后，我开始用 Python 配合 AI 写脚本。

最后，有一类原本要几天完成的工作，被压到了半天左右，脚本后来也被团队反复使用。

这是我第一次很明确地感受到：

AI 不只是让我“学得快一点”，它可以直接改变工作的成本。

以前我会觉得“会写代码”是一种能力。

从那以后，我开始更在意另外一个问题：

能不能把一个重复问题变成一个以后不用再重复解决的工具？

这个习惯后来一直没变。

写博客麻烦，就想做编辑器。

项目状态太乱，就想做状态系统。

知识太散，就想做 Book Voice。

很多项目最开始其实都不是“我要创业做一个产品”，而是：

这个问题我已经遇到第三次了，能不能直接把它解决掉？

03｜真正的转折，是我第一次接触 Coding Agent

2026 年 5 月左右，我开始认真接触 Coding Agent。

这对我的影响比任何一个新框架都大。

因为以前用 ChatGPT 写代码，本质上还是：

问一句
↓
拿一段代码
↓
复制进去
↓
报错
↓
继续问

Coding Agent 不一样。

它可以读仓库、找文件、改代码、执行命令、跑测试。

于是我的角色开始变化。

以前我需要关心：

这一行代码怎么写？

后来我开始关心：

这个任务应该怎么定义？

哪些文件允许改？

做完以后怎么判断真的完成？

如果 Agent 理解错了，怎么恢复？

AI 从“代码生成器”变成了“工程执行者”。

而我自己的工作，也从逐行实现，慢慢往：

定义问题、拆任务、设计边界、验收结果

移动。

这是我第一次真正理解 AI Native 开发和“用 AI 辅助写代码”不是一回事。

04｜做 Agent 以后，我开始关心“它做错了怎么办”

刚接触 Agent 的时候，我最关心的是能力。

它会不会调用工具？

会不会自己规划？

Memory 怎么做？

RAG 怎么接？

后来做了几个真正的 Agent 项目以后，我发现最重要的问题反而不是这些。

而是：

它做错了怎么办？

有一次做一个数据审核类 Agent，我开始给系统加：

  • 状态机
  • Tool Contract
  • 人工审批
  • 审计
  • 异常预览
  • 自动测试
  • 原文件保护

这时我才慢慢意识到：

Agent Engineering 的核心，不是让 AI 拥有更多能力，而是让能力处在可控边界里。

后来做 Phosphene 时也是一样。

内容不是模型生成完就结束。

而是：

采集
↓
清洗
↓
证据
↓
初稿
↓
质量检查
↓
人工审核

AI 越往真实业务里走，越不能只有“生成”。

还要有：

验证、权限、审计、失败恢复和人工接管。

这也是我后来越来越想做 FDE 的原因。

我发现自己真正感兴趣的，不是单独研究模型，而是把 AI 接进一个真实流程，然后把它交付出来。

05｜我也踩过一个很典型的坑：项目很多，但没有用户

AI Coding 提高开发速度以后，会出现一个很诱人的问题：

做东西太容易了。

有想法，几天就能有 Demo。

页面不好看，再改。

想加功能，再加。

结果很容易变成：

功能越来越多
↓
项目看起来越来越完整
↓
但没有人真正使用

2026 年 7 月左右，我开始明显反思这件事。

后来我给自己换了一套顺序：

先找真实问题
↓
和提出问题的人聊
↓
做最小版本
↓
让他直接试
↓
记录失败和反馈
↓
有必要再继续产品化

这对我影响很大。

以前我会问：

什么项目看起来高级？

现在我更愿意问：

有没有一个真实的人，现在就被这个问题困扰？

技术栈反而放后面。

06｜Book Voice 让我开始研究：能力能不能被保存下来

差不多同一时期，我开始长期做 Book Voice。

最开始的问题很简单：

一本书除了放进向量数据库做问答，还能不能保存得更深一点？

我不太满足于：

PDF
→
切块
→
Embedding
→
RAG

因为一本书真正有价值的东西，不只是句子。

还有：

  • 核心概念之间的关系
  • 论证链
  • 方法
  • 思维模型
  • 作者怎么看世界
  • 什么条件下适用
  • 什么情况下会失败
  • 证据来自哪里

所以后来 Book Voice 越做越像一套“认知加工协议”。

开始出现：

  • Factory
  • Artifact Contract
  • Validator
  • Eval
  • Runtime
  • Gate

这个项目让我开始反复思考一个问题：

AI 的能力，到底应该存在 Prompt 里、模型里、Memory 里，还是一个外部结构里？

后来我发现，这个问题不只适用于书。

写作方法、工程经验、项目规则，甚至一个人的长期状态，都有类似的问题。

重要的东西不能永远只存在于一次聊天的 Context 里。

这也是我后来做 Personal OS、写 AGENTS.md、做各种 SOP 的一个共同原因。

07｜真正做大项目以后，我开始被“复杂性”教育

到了 2026 年 8 月底、9 月，我开始用多个 Coding Agent 推一个更大的业务系统。

这一次问题完全变了。

以前一个 Agent 改错，最多回滚几份文件。

多仓、多模块、多 Agent 以后，问题开始变成：

  • Agent 读到了旧方案
  • 文档写着 Done，代码其实没有完成
  • 一个任务顺手改了另一个模块
  • 两个地方维护了同一个业务事实
  • Agent 在错误的仓库开始工作
  • PR 合并了，但状态文档没更新
  • 状态文档更新了，但测试没有通过

有一天我甚至发现：

项目做了很多，但我已经不知道它到底完成了多少。

这件事对我冲击挺大。

也是从这里开始，我真正理解：

大型项目不是一个更大的 Prompt。

它更像一个状态机。

项目现在在哪一步，下一步允许做什么，完成的证据是什么，都应该是确定的。

于是我的开发方式开始变成：

Requirements
↓
Architecture
↓
Roadmap
↓
ADR
↓
Task
↓
Implementation Agent
↓
Independent Review Agent
↓
Test / CI
↓
人工确认
↓
Merge

执行 Agent 拿到的 Context 也开始越来越少。

不是把几千行总文档全塞给它。

而是只给：

当前任务真正需要知道的东西。

我现在越来越相信：

Coding Agent 的上限，很大程度上取决于你给它设计了什么工作环境。

模型很重要。

但 Context、边界、状态、验证，同样重要。

08｜我对“完成”的定义也变了

以前做项目，页面出来了、功能能点，我就很容易觉得：

做完了。

现在我越来越不敢这么说。

我会继续看：

  • 代码真的在正确分支吗？
  • 测试通过了吗？
  • PR 真的 Merge 了吗？
  • Changed Files 有没有越界？
  • 文档和代码一致吗？
  • 当前状态是 READY 还是 DONE？
  • 有没有第二个 Agent 独立检查？

因为我被一个问题反复教育过：

“Agent 说完成了”和“事情真的完成了”，是两件事。

这也慢慢影响到别的地方。

写简历，我开始要求每一句都能经得住追问。

写文章，我开始更喜欢放真实过程、失败和证据。

做产品，我开始区分设计过、实现过、上线过、有人用过。

这些词看起来只差一点。

但真正做事的时候，差别很大。

09｜现在我越来越少追“最强工具”了

我以前很喜欢找新东西。

新模型、新 Agent、新 Skill、新 Coding 工具，都会想试。

现在依然会试。

但判断方式变了。

我会先问：

它到底解决我工作流里的哪个瓶颈？

和现有工具怎么分工？

是真的需要，还是只是多装了一个东西？

最后真正留下来的，反而不是某个具体工具名。

而是这些东西：

Context
Task Boundary
State
Permission
Verification
Review
Recovery
Observability

工具一直会换。

这些问题不会。

10｜回头看，我真正学会的可能不是“怎么用 AI”

如果把这几年压缩一下：

2023 年，我主要在问：

AI 能不能帮我把这个问题做出来？

后来变成：

AI 能不能直接帮我提高工作效率？

再后来：

Agent 为什么能自己完成工程任务？

接着是：

怎么把 Agent 真正交付出去？它做错了怎么办？

现在更多是：

怎么让多个 Agent 长期工作，而系统不会失控？

所以我自己的变化大概是：

使用 AI
↓
利用 AI
↓
构建 AI 产品
↓
理解 Agent
↓
构建 Agent
↓
约束和验证 Agent
↓
管理多个 Agent
↓
设计 AI 的工作方式

我现在依然只是一个在学习的软件工程学生。

也还有很多明显的短板：算法基础需要继续补，项目太多容易分散，做系统时也很容易陷入“把架构做得越来越完整”而忘了用户。

但至少有一件事比几年前清楚了很多。

我不再把 AI 理解成一个聊天框。

对我来说，它越来越像一种新的工程组织方式。

真正值得学习的，不只是怎么让模型更聪明，而是怎么让人和 AI 一起把事情做完。