2022 年末，ChatGPT 刚刚开放不久，我正在乐天参与大数据 Web 采集端 SDK 的开发。听说它能写代码后，我很快跑去试了一遍，让它替我补充单元测试。
结果比预想中好。生成的大部分测试稍加修改便能使用，比从头手写省事得多。我后来也尝试让它为 React Component 编写测试，内容看起来像模像样，但经常无法正常运行。代码读起来合理，放进真实项目却未必成立，这是我第一次清楚看到大模型能力与工程交付之间的距离。
当时我以为，AI 最实际的价值，就是替工程师少写一些重复代码。几年后的今天，它已经能读取整个代码库、检查日志、制定修复计划、修改文件并运行测试。回头看这段 AI 智能体发展历程，变化最大的并不是模型越来越会回答问题，而是它开始离开聊天框，进入真实工作环境。
从一个不太可靠的聊天框开始
最初使用 ChatGPT 时，我很快把它变成了每天都会打开的工具。很多人还在讨论聊天机器人除了对话和简单问答还能做什么，我已经开始让它补测试、解释代码、生成组件。
不过，我一直没有完全相信它。
2023 年，ChatGPT Plus 开始提供网页浏览能力。为了适应这种新工具，每当需要搜索资料时，我会强迫自己先问 AI，再打开浏览器做一遍相同搜索。它给出的答案经常需要复核，有时来源不清，有时把错误信息组织得十分流畅。可我仍然喜欢它提供的摘要，因为它能替我完成最耗时间的初步筛选。
那段时期，我的使用方式始终没有发生根本变化：我向 ChatGPT 提问，它给我一段内容；我复制出来，放进编辑器或终端，再判断能不能用。它能协助工作，却不能接手工作。
与此同时，大型科技公司迅速进入 AI 竞赛。微软早早押注 OpenAI，并把相关能力放进 Edge、GitHub Copilot 和 Windows；Google 用 Gemini 连接搜索、Workspace、Android 和云服务；OpenAI 也不断为 ChatGPT 增加搜索、工具调用、多模态和复杂推理能力。
这些发布会很热闹，但对我来说，判断变化是否重要只有一个标准：它有没有改变我每天工作的方式。
从给出答案，到接过任务
聊天工具与工作智能体之间存在一条清楚边界。
聊天工具告诉我代码应该怎样改，剩下的事情仍由我完成：找到文件、复制代码、解决上下文缺失、运行测试，再把错误贴回对话框。工作智能体则能直接进入项目，读取代码库，搜索相关实现，检查日志，提出修复方案，修改文件，并调用真实环境中的工具验证结果。
它提出的问题也开始变得有价值。有时，一个问题会迫使我重新检查需求、边界条件或原先默认成立的判断。此时 AI 不再只是回答者，也参与了问题定义。
2025年前半段我还在使用Neovim 的 Code Companion 插件来做代码补充。这时候的我已经觉得自己能够在软件编程上更上一层楼了。每敲击几个字符，然后使用Tab键辅助完成那一行甚至几行程序。
比如下面这个 LanguageSwitch.tsx 的一个组件，我仅仅写了一行。剩下所有的内容都是 Copilot 和 Neovim 插件填充的。尽管刚生成出来的代码在开发过程中产生了一些问题导致不能直接使用，当我把错误提示给 Copilot 之后，他马上找到错误，并提出修改方案（下面贴出来的代码已经是修改好的了）。紧接着通过 Code Companion，修改的内容可以直接替换进当前文件。
# LanguageSwitch.tsx
'use client'
import { Languages } from 'lucide-react'
import { usePathname } from 'next/navigation'
import Link from '@/components/Link'
import { getLocalizedPath, getLocaleFromPathname, getOppositeLocale, getTargetPath } from '@/lib/i18n'
# I only wrote the below line of function LanguageSwitch. Rest is all "tabbed-out". And it's working!!!
export default function LanguageSwitch() {
const pathname = usePathname()
const isEnglish = pathname === '/en' || pathname.startsWith('/en/')
const targetPath = getTargetPath(pathname)
return (
<Link
href={targetPath}
className="inline-flex items-center gap-1.5 text-sm font-semibold text-gray-900 underline-offset-4 hover:text-primary-500 hover:underline dark:text-gray-100 dark:hover:text-primary-400"
aria-label={isEnglish ? 'Switch to Chinese' : 'Switch to English'}
>
<Languages className="h-4 w-4" aria-hidden="true" />
{isEnglish ? '中文' : 'EN'}
</Link>
)
}
如果我要完成的功能跟其他的文件有关联，那么我可以提示 Code Companion 去加载那些文件，有时候我不得不把代码或者上文直接粘贴在对话里来增强上下文关联性。
# Read the below files
./src/LanguageSwitch.tsx
./src/lib/i18n.ts
./src/components/Link.tsx
能用这样的方式写代码很酷，只需要我们在同一个环境里不断提交想法和上下文，产出的东西就能直接拿来使用。
而当Claude Code 出现后，我对这种变化感受尤其明显。虽然早期的 Claude Code 需要大量的“用户确认”来保证AI行为的合理性（这个可以通过 dangerous mode 取消掉，很多类似于openclaw之类的自动任务执行智能体就是这么做的），但是它已经能自己通过思考来解决文件内容。
它还可以在 terminal 中直接工作，不需要在聊天框和编辑器之间反复搬运内容。对于已经习惯 tmux 和 Neovim 的我来说，学习成本反而不高，只要在熟悉的环境里启动工具，便能开始协作。
在智能体还不完善的那段日子里，不少人还把 VS Code 和 JetBrains IDE 当作开发工作中心；智能体工具普及后，terminal 又变得热闹起来。看起来像是开发者集体回到了更原始的界面，但发生的事情正好相反。
Anthropic 还提出了非常令人兴奋的 Skills 功能，对于我这种对写代码相对比较高的人来说是个顺手的工具。Claude Code 或者 OpenAI 的 Codex 虽然都能把代码写出来，而且在一定程度上不太需要修改就能做到能用。Skills 就好像是游戏里的增强技能，Skill 1 能增强瞄准，Skill 2 可以提高奔跑速度，Skill 3 能提高准度。你需要有多个skill进行合作才能最大化产出。
渐渐的，像 caveman 和 using-superpowers 成为了我日常必用的 Skills，而且我发现自己也越来越依赖它们带来的增强效果。虽然感觉会比以前烧掉更多的token，但看到产出能达标的瞬间还是觉得物有所值。
我觉得智能体所带来的，不像是新技术出炉时人们需要刀耕火种才能获得的便利。它更像《黑客帝国》一样，单纯给你加载一段代码，你就能开直升飞机了。
新概念出现得比学习速度更快
ChatGPT 爆火后，“提示词工程师”迅速成为热门词汇。早期模型上下文较短，社区里流行过大量关键词式提示词。一个词是否出现、顺序怎样调整，都可能明显影响结果。大家一边寻找更稳定的表达，一边想办法减少上下文消耗。
那时，提示词工程的价值很直接：在有限窗口中，用更少输入换取更可控的输出。
此后变化不断加速。2023 年，function calling 让模型能够以结构化方式连接软件工具；RAG 和长上下文逐渐进入大量产品；Anthropic 在 2024 年末发布 MCP，为智能体连接数据和外部系统提供统一协议。2025 年，Claude Code、Codex、Cursor 等 coding agent 开始把关注点从“模型会不会写代码”推向“它能不能在真实工程环境中完成任务”。
工具、权限、沙箱、文件系统、测试、上下文压缩和人工审批，开始共同决定智能体上限。我习惯把它理解为一种“统驭工程”：重点不再是写出一句完美提示词，而是建立一套让智能体可靠行动的环境。
到了 2026 年，又有人开始讨论 loop engineering，研究如何设计智能体的执行循环、验证机制、失败恢复和上下文更新。名词一层叠一层，每个都像是下一阶段必学能力。
问题也在这里出现：工程师时间有限，但新概念没有停止按钮。
日常试用，但不急着深入
在技术爆发期，我觉得“不盲目深入”是一种好习惯。这不是告诉你要拒绝变化，而是一种时间分配方式。
我仍然会关注新模型在推理速度、准确度、格式控制和工具使用方面的变化，也会试用成熟产品处理真实工作。但我不会为了没有落地场景的记忆机制或 Agent 理论，提前阅读大量论文和源码；也不会因为一个新框架突然流行，马上重构现有系统。
过去几年已经反复出现类似情况：某种复杂编排方式刚被视为未来标准，几个月后便可能被底层模型能力提升直接覆盖。这样的例子有很多，我们可以前几年的提示词工程，one shot 和 few shot 技巧现在虽然可以用，但模型早就不需要用这种方式增强任务定义了。
所以，投入越早，不一定回报越高。
现在遇到新工具，我会先看几个信号：它是否已经存在三个月以上，是否有足够媒体和用户讨论，是否有人在真实工作中复现生产力。如果是 GitHub 项目，我还会看 fork、维护频率和社区活跃度。Fork 数超过一千是我常用的粗略门槛，但它只能说明项目获得了一定关注，不能替代实际判断。
通过第一轮筛选后，我通常试用三天。三天足够判断它能否解决现有问题，也足够看出它是准备进入工具箱，还是只能提供一次短暂的新鲜感。日常试用保证我不会掉队，同时等待该技术沉淀能避免我成为每个新概念的陪跑者。
我会在三种情况下重新投入时间：
- 工业界已经形成基本共识。
- 复杂能力被封装成稳定接口，学习成本明显下降
- 真实工作流出现瓶颈，深入理解能够直接产生收益。
除非工作本身就是研究这些技术，否则没有必要在每次浪潮刚出现时冲到最前面。
Skills 保存的不是提示词，而是工作经验
Agent Skills 改变了我对智能体能力扩展的理解。
Skill 不只是更长的提示词。它可以包含操作规范、脚本、参考资料和检查标准，让智能体在需要时加载特定能力。模型负责推理，Skill 保存经过验证的工作方法。
我实际使用过很多 Skills。我发现像 caveman / using-superpowers / ponytail / frontend-design 可以给我的工作带来巨大的ROI。
caveman 用来减少客套话、重复解释和无效总结。它保存的是一种高信息密度协作习惯：只保留结论、依据、代码和下一步。阅读负担降低，上下文也不会被套话占满。
using-superpowers 保存复杂任务拆解和工具调度经验。面对大型工程，单靠文本生成容易停留在表面；这类 Skill 会告诉智能体何时调用子 Agent、自动化脚本、测试工具或外部系统，把团队解题方式变成可执行流程。更重要的是他能留存很多文档，给后续工程任务提供了不少上文。唯一可惜就是会烧掉不少 token。
ponytail 保存资深审查者的检查视角，包括边缘情况、性能瓶颈、安全风险和代码规范。在此基础之上用最少的代码交付来完成任务。如果我每天都需要代码的话，ponytail是几乎必敲的skill。
frontend-design 解决了 AI 容易生成样式混乱、缺少一致性的界面问题。能使用 Tailwind 类名习惯、组件复用、响应式布局与自定义配色原则。我大多数会拿来做一些 demo 或者高精度模版。
这些内容不是第一性原理，更接近程序性知识和组织记忆。模型会更新，工具会替换，但经过长期工作验证的审查标准、设计规范和协作流程可以留下。
当一个团队开始持续沉淀这些 Skills，并留存大量使用文档和体验感悟。智能体获得的便不只是额外功能，而是组织过去解决问题的方式。相比追逐某个短期热门框架，我认为这种团队的积累更值得投入。
我害怕的不是 AI 会写代码
智能体能力越强，裁员新闻带来的压力越具体。
我不只担心工作被 AI 直接夺走。我更担心年轻工程师借助搜索和智能体，快速获得过去需要多年积累才能达到的产出能力。身边一些初级工程师已经能通过搜索和 AI 对话完成质量不错的任务，这种变化很难忽视。
我在 FastRetailing 的团队里深切感受到了有时初级工程师能带来优秀的代码。他们虽然没有那么多经验可循，但是智能体可以提供更多上下文。通过调查和学习，初级工程师一样能提交像样的PR。说实话，尽管我自己工作这么多年，我也不敢说纯靠自己敲代码而提交出来的PR能像那些初级工程师+智能体做出来的玩意一样可靠。
甚至是做架构设计，只要工程师能掌握足够的上文，那么资历其实是可以被AI抹平的。为什么？你先看看那些AI在几十分钟内产出的设计文档、流程图、时序图、对象结构图，内容大体上准确无误。而当我们花了一整天时间（有时甚至可以是一周）做好了这些设计文档和图，好像可以开始拿它来当作开发文档了，结果在review和discussion的时候仍然能被指出多个问题。
如果说资深工程师更了解自己的系统架构，做出来的设计更贴近真实需求且可以避免缺少冗余带来的副作用。你拿设计文档做一下对比就知道作为资深工程师所花的时间是否值当了。毕竟我们在使用智能体做设计的时候要提供大量的上文给AI，此时AI才是那个更“资深”的工程师。
那么如果说我们有办法能让初级工程师获得这个大量的上文呢？结果不言而喻了。
如今媒体不断讨论“一个资深工程师借助 AI 完成过去一个团队的工作”，招聘市场也传出软件岗位收缩信号。与此同时，我开始频繁看到 FDE，也就是 Forward Deployed Engineer 岗位。它要求工程师进入客户真实环境，把技术能力、业务理解和交付责任放在一起。这至少说明，企业需要的可能不再只是写代码的人，而是能够把模糊问题变成结果的人。
这种变化同样影响初级工程师。AI 能降低完成基础任务的门槛，也可能减少企业用初级岗位培养人才的动力。入口变窄后，我觉得年轻人面对的压力不会比资深工程师更小。
我暂时仍然相信，人需要在三件事上承担更大角色：品味、判断和责任。
品味决定什么结果值得留下；判断发生在信息不完整、规则不明确的时候；责任意味着有人必须为投资、招聘、产品策略和系统风险拍板。智能体可以分析、推荐和生成，但目前承担后果的仍是人。
这不是永久保证。它只是我在当前阶段看到的人机边界。
电话行业提供过类似但有限的参照。早期电话交换系统曾创造大量人工接线岗位，自动交换系统随后用几十年逐步替代其中一部分，同时产生设备工程、维修和网络管理工作。这个历史不能证明 AI 必然创造更多岗位，只能说明技术通常会重新划分工作，而不是按照旧岗位名称原样延续。
今天最难回答的，可能不是“程序员会不会消失”，而是“哪些工作仍值得由程序员负责”。
我不再制定五年技术路线
这些变化已经影响了我的职业规划。
过去，工程师习惯制定一条五年技术路线：学习某种语言，进入某个架构方向，再逐步积累框架和系统经验。现在，我越来越难相信一条固定路线能覆盖未来五年。
我的选择是建立模块化技能库。
一部分模块属于基础能力，例如系统设计、调试、测试、安全和性能；一部分属于业务知识，来自长期接触真实系统和用户；另一部分则负责连接 AI，包括工具选择、任务拆解、权限控制、结果验证和 Skills 沉淀。
模块可以替换，也可以重新组合。当某个 AI 范式形成稳定标准时，我不需要从头改变职业方向，只需要把它接入现有能力体系。
不追赶每个泡沫，是为了把时间留给业务壁垒和真实问题；保持日常试用，是为了让重要变化到来时，我仍然知道应该从哪里进入。
2022 年，我让 ChatGPT 为 SDK 补几段单元测试，生成结果还需要手动复制、修改和运行。几年后，我已经可以把整项任务交给智能体，让它读取环境、执行操作并验证结果。
工具完成的部分越来越多，我需要负责的部分也变得更清楚：决定什么值得做，判断结果能否接受，并把有效经验留下。
这可能就是我从这段 AI 智能体发展历程中获得的最大变化。
