从ChatBot到Vibe Coding，从对话到工程。这是真实的踩坑记录。
先讲一个公式
这一年踩了无数坑，最后我找到一个判断：
AI时代拿结果的能力 = 行业能力 × AI能力 × 工程能力
三个都是乘法项。任何一个为零，结果就是零。
行业能力——你对某个领域的深度理解和交付能力。用户在哪痛，市场逻辑是什么，什么东西值钱、什么东西能卖。
AI能力——对AI这种新生产要素的基本认知。模型和Agent的区别，什么场景该用什么AI。
工程能力——把行业理解”翻译”成AI可以执行的结构。哪些任务能拆解，如何让AI稳定产出，什么时候该介入，什么时候能放手。
行业能力可以靠时间磨出来，AI能力可以学出来，但工程能力，必须实打实地干出来。
但我要先诚实地说：这篇文章不适合所有人。如果你只是想让AI帮你改改文案、做做图，看到这里就够了。如果你试过用AI做工具但总觉得哪里不对，那下面这四段弯路，可能也是你要走的。
四段弯路总览
第一段：Prompt阶段——我以为对话就是开发
2025年初，DeepSeek之后
和大多数人一样，我从ChatBot对话框开始。输入问题，等AI回复，再输入，再等。
概念科普：ChatBot就是像ChatGPT、Claude那样的聊天界面。Prompt是你给AI的指令，System Prompt是给AI设定的底层”宪法”，比如”你是一个专业的营销顾问”。
很快我发现：结构化的指令比随意提问有效得多。角色、任务、背景、格式——把这四样说清楚，产出会好很多。
然后我开始多窗口嵌套，人工搬运信息。给ChatBot加了一段System Prompt，就觉得自己”开发了一个Agent”。
现在回头看，那叫什么Agent？那是穿了马甲的对话框。没有手（不能调用工具）、没有规划（不会自己拆解任务）、没有记忆（每次对话都从零开始）。
但这个阶段我确实学到了东西：学会把模糊的想法翻译成AI能处理的结构化语言。这是后来所有能力的地基。
问题是：人变成了流程里的搬运工。每次都要重新交代背景，每次都要检查AI有没有理解错。我以为我在管AI，其实是AI在管我。
那时候其实挺兴奋的，觉得自己发现了一种”新工作流”。但兴奋背后是一种隐形的累——你始终要盯着，不敢放手。
第二段：低代码幻觉——以为拖拉拽能绕过技术
折腾Coze、Dify的那两个月
知道了Agent需要Model + Memory + Tools，我开始折腾低代码平台。拖拉拽就能搭建AI应用，听起来很美好。
概念科普：Coze（扣子）、Dify是国内低代码AI平台，像搭积木一样不用写代码就能做应用。它们封装了很多底层细节，让非技术人员也能上手。
那段时间我的感觉是：AI的世界好像在向我打开了。
结果：一看产出二百五。
部署是噩梦。Docker、环境配置、API接入——每一个都能卡一天。国内生态基本封闭，花时间接进去，发现能用的工具几乎没有实用价值。
产出极低。折腾了几天，就做出一个RSS抓取+整合的脚本。能用，但没有任何业务意义。还得花时间学平台的封装逻辑，边学边绕，云里雾里。
最痛苦的是确定性陷阱。低代码平台的本质是预定义路径，但真实业务充满分叉、回退、例外。越想用确定性的工具覆盖不确定的业务，越痛苦。
我直接选择放弃。这些平台把我困在它们自己的逻辑里，而不是帮我处理我的业务逻辑。
有段时间其实很沮丧。明明投入了时间，却做不出想要的东西。看着平台上别人的”成功案例”，怀疑是不是自己太笨。
第三段：地图阶段——我看懂了，但不会开车
LangChain/LangGraph时期
放弃拖拉拽后，我转向开源框架。有一点Python基础，决定直接去源头看看。
概念科普：LangChain和LangGraph是开源AI应用开发框架，用Python编写。LangChain像流水线，把AI任务串起来；LangGraph像带共享白板的状态机，Agent可以条件跳转、回退重试。
我终于理解了Agent系统的底层架构：
概念上我懂了。但懂概念和能造系统之间，有一道很宽的沟。
那段时间工作很忙，每天只有下班后一两个小时。用纯代码构建复杂系统，效率太低——更多时间花在查语法和调试上，而不是思考业务逻辑。
但这个阶段给我留下了一张地图。我知道Agent系统长什么样，知道工作流和Agent的区别，知道状态机的概念。这张地图后来救了我很多次——当我用更好的工具造系统时，至少知道自己在造什么。
但说实话，那时候有种”看懂说明书但不会用”的憋屈。明知道前面有什么，但就是到不了。
第四段：Vibe Coding阶段——从能做出东西，到想开一家公司
这一段其实经历了三个场景 Cursor → Trae → Claude Code，但本质都是Vibe Coding——在代码车间里用自然语言指挥AI，让AI帮我写代码、改代码、跑测试。
场景一：Cursor——第一次做出能用的东西
知道Cursor后，我第一次觉得”可控”。
概念科普：Cursor是AI原生的代码编辑器。你能看到AI打开哪个文件、写了哪行代码、在哪里停下来问你意见。这叫Vibe Coding——vibe对了，代码就出来了。
什么是可控？就是AI写代码，但决策权在我手里。它写前端样式，我要判断好不好看；它设计API，我要理解它在做什么。
我做了一个粗糙的数据分析产品：上传数据，AI给出可视化结论。
这个项目最大的收获不是功能本身，而是第一次看清了”做一个产品”的全貌——需要产品文档（想清楚做什么）、前端（用户看到的界面）、后端（数据处理逻辑）。不同的部分需要不同的能力栈。
但我心里清楚：这只是AI带我飞了一遍，自己还没学会扇翅膀。看得懂代码大意，但不懂为什么这里要异步、那里要加缓存。
场景二：Trae——试图在文件夹里开一家公司
Cursor让我看到了可能性，但功能有限。我转向Trae IDE，字节跳动的AI编程工具，开始更大胆的尝试。
概念科普：Trae和Cursor类似，但有更强的Agent调用能力。MCP（Model Context Protocol）是一种让AI连接外部系统的协议，比如操作你的飞书文档。
目标：用Vibe Coding重构日常工作流。
写文章、做HTML PPT、数据分析报告——这些原本分散在不同工具里的任务，我想全部搬到Trae里，用Agent完成。
这个阶段我一边Vibe一边疯狂补课：
- 学会了看个大厂商和产品的开发者后台、API Key、权限配置、接口文档
- 想用AI管理日程，自己Vibe了一个MCP连到飞书，过程中摸清了OAuth、Token管理、请求签名
- 把手头技能一个个Skill化：写内容、数据清洗、排版、写文章、出配图
- 被动学会了很多”代码语言”——YAML写配置、JSON存数据、HTML/CSS做前端、Python处理逻辑
是一个极其混乱的阶段，当我尝试把这些都联系和联动时，真正的混乱开始放大了。
我想让数据分析Agent分析原始数据 → 输出可视化图表 → 内容Agent优化语言 → Skill输出报告。听起来很美好，实际跑起来是灾难。
- 上下文污染——前一个Agent的图表数据，到后一个手里根本没被有效引用；
- 内容质量下滑——每个Agent都在”优化”，最后既不是准确分析也不是人话，数据血缘也错误；
- 文件边界不清——Agent根本不知道它该干嘛，产出的东西很乱，找的我很累；
陷入80%时间调教、20%时间产出的低效阶段。每天都在修Bug，修完一个接一个。
我还发现用AI生产内容会是最简单的切入点，会有越来越多的人用AI生产内容，自媒体竞争会进一步加剧。
如果我只是停留在”用AI做内容”，没有更深的能力积累，迟早淹没在这场无意义的声量和喇叭战争上。
回到用Trae去做复杂项目的经历上，最难受的是”剪不断理还乱”的感觉——文件越来越多，规则越来越复杂，系统却越来越脆弱，产出质量越来越低，人也越来越累。
我意识到Trae有能力边界，我也有能力边界。当我的能力不够，Agent的能力也不够时，就变成了两个人互相折磨的体验。
场景三：Claude Code——进入终端，提炼自己的设计哲学
Trae不够，那我试试市面上最强的AI工程工具。如果说用Trae的时候我是混乱且发散的阶段，那么在Claude Code上我是一个收敛和精简的阶段。
概念科普：Claude Code是Anthropic的终端级AI工具，没有GUI界面，完全通过命令行操作。它暴露的是完整的Agent运行机制。我是搭配官方的模型sonnet4.6来一起使用的。
使用Claude Code的第一感受：确实不一样。同样是自然语言描述需求，Claude Code的意图识别更准确；复杂任务的执行效果也更稳定。哪怕换成kimi的模型，也比直接使用kimi k2.5的结果来的更好。
产出质量更高的同时，废话也不多，但确实用起来是真贵。之前用Trae一个月差不多500的消耗玩玩。用Claude Code+soonet4.6之后一个月的消耗直接干到2000+，但收获也是真的明显。
我开始思考，为什么Claude Code的效果这么好，好在哪里？
我开始找一些关于Claude Code的拆解和分享，找到了几个Claude Code的关键设计哲学：
- 上下文是重要的资源，需要被珍惜和精确管理
- 渐进式披露：只给Agent当前需要的信息
- Subagent的干净上下文窗口：每个子任务有独立的、不受污染的思考空间
- 安全和准确性的审阅是底线
同时我还发现：真正优质的信息源基本都不在国内，也不在社交媒体上。
Anthropic/OpenAI官网、Google Cloud白皮书、GitHub开源项目、X上工程师的思考——这些地方有更优质的系统化的一手信息。国内资料大多是几手加工，看不到来龙去脉。
同时我也看到了Trae有但Claude Code没有的东西。比如Trae把Agent调用设计得更加傻瓜化就是，虽然本质上就是 @一个文件，但在C端确实更友好，但也失去了探索这个功能的底层原理的机会。那这本质上是服务受众不同+产品哲学不同带来的设计哲学不同。
这些理解迫使我回头思考：我自己用AI的目的到底是什么？服务我目的的设计哲学是什么？
我用AI的本质就是希望把我工作上碰到的整合营销这件事塞到一个上下文语境中。
整合营销是什么，是将所有与品牌相关的渠道、工具、资源、产品等进行协同整合，向目标受众传递统一、清晰、一致的品牌信息和营销体验的过程。我觉得程序员这种IDE的集中式环境特别适合营销行业的整合营销业务。把多源混乱的信息塞到一个系统中处理，减少信息的损耗和处理带来的低效，所有的信息输入输出和反馈都能在一个产品中看到。
于是我开始引入我对品牌营销和整合营销的理解，我觉得品牌就是一种超脱现实的哲学愿景，哲学在现实世界要有解释性就需要一套系统承载，而在过往的人类历史上，数学这套系统的一致性经受住了时间的考验。或许可以试图用数学系统的构建思维来承接我用AI构建系统的目的和愿景。
于是我开始用”数学大厦”的构建过程来思考如何把目的和愿景融进Agent体系，我设计了几个文件，标注了层级，
这个分层解决了Trae阶段最让我头疼的问题：规则到处重复，越改越乱，找不到根和出口。但这里面的东西很多也不是一簇而就的，都是要耐着性子在循环项目实践中总结和反思出来的。一边试一边丢，慢慢地就找到了自己最想要的。
除此之外，再分享一些当下我的一些设计进展，我好像找到了一点点把营销项目一致性管理和AI系统结合的路径。
比如，我针对项目执行，设计了一个项目容器：
我把每个复杂项目当作一个游戏关卡——有明确目标、边界、进度。用一个Project文件夹来存储，里面有PROJECT.md的项目地图索引，包含背景、需求、目标、整个项目的文件索引、备注信息等。里面还有state.yaml的项目状态存储，里面会记录具体的执行状态，包含什么agent做了什么事情，包含history、current、next等核心字段。会话可以崩溃、上下文可以满（需要 /clear），但只要state.yaml+PROJECT.md在，状态就不会丢。
麻烦的是要半主动维护，我在我的ops.md中增加了相关的说明，大多数情况Agent做完一个动作到结束时，会主动进行更新，有的时候上下文多了（一般是60%-70%），维护效果就会变差，这个时候就会需要人工主动维护。
除此之外，我还设计了：域划分（内容域/工作域/测试域）、动作层级（系统级/项目级/计划级/动作级）、Skill的IPO协议、文件格式体系（YAML存状态、Markdown写规则、JSONL记日志），不同的Skill负责不同的动作层级，不同的Agent负责不同的域…
到现在，我真正感觉到自己有点从”和AI聊天/用AI做内容”进化到”设计面向AI的系统来处理复杂问题”的系统的感觉了。
但说实话，还是会经常性地感觉很崩溃。但所有的一切都来源于，我觉得我看到了一种AI大力发挥的可行性。
现在我对很多东西都有了更深的了解，但试图把这些变成真正能用的产品，还有不少路要走。尤其是代码/软件工程的知识，缺口还在。值得庆幸的是，AI时代的软件工程，可能不再是过往那套学习路径。
我从混乱中逐渐找到了走出来的方式，既因为找到了更强大的工具，也因为逐渐理解了工具背后的原理，还因为有了自己的思考，提炼出来了一些以不变应万变的原则。
如果你是非技术人员，也走在用AI去创造的这条路上，我有一些四条不太一样的建议
第一，先搞清楚你的行业能力值几分。
不是每个人都适合从AI工程入手。如果你已经有了一定的行业沉淀，请用AI继续加深。如果行业理解不够深，你把AI工具学再熟，产出的也只是通用的、没有护城河，甚至市场不会买单的东西。我坚信未来AI会横向洗刷所有行业80分以下的东西。找到自己在某个行业里面超过80分的点，用AI去放大它。
第二，Vibe Coding+Skill是目前最值得投入的学习AI的切入点。
不是让你学代码语法，而是进入一个能看到代码、理解结构、能用自然语言指挥AI生产代码的环境。AI就像一种虚拟人种或生产原料，你要学会AI，就要去到它真正所处的生产环境中去了解它的机制。比如找Cursor或Trae这种AI Native的IDE，拿一个真实的业务问题去试，去问，去理解。尤其是Skill的使用，基本上是未来AI生产的重要底层基础设施。
就像短视频，拥抱短视频不是让你去刷短视频，而是去短视频的生产车间里面去搞明白一个好的视频是怎么出来的。AI同理。
第三，工程化思维比代码能力更关键。
Coding Agent的能力我相信会被顶级工程师们轰到一个超高的水准。你不需要会写代码，但需要在和AI配合的过程中理解”系统是怎么设计的”。文件是什么，格式是什么，状态是什么，规则是什么，信息是怎么流转的，自己的业务怎么用这些东西定好——这些决定了未来你能把AI在某个业务上用到什么深度。说专业点，围绕Agent构建稳定性的Harness系统才是更重要的。
有个OPEN AI工程师翁家翌的采访中有一句话我觉得挺对的，教Research的人做Engineering，比教Engineering的人做Research难。工程化能力没有捷径，但只要你在解决真实问题，这个能力就在积累。
第四，不要被FOMO带跑。
AI工具每天都在更新，新概念层出不穷。我认为底层能力只有三个：行业能力 < AI认知 < 工程落地。这三个不会因为某个工具被替代而归零。需要根据自己的实际情况想明白自己应该加强哪些能力。同时我认为三者难度是依次递增的。
最后，问自己一个问题：如果我想做什么就能做什么，那么我最想做的是什么？AI让路变多了，但依然无法解决你为什么出发的问题。
我的四段路径总结供你参考
以上是我这一年真实走过的四段路。这不是标准答案，但如果你也在学AI，不知道接下来该往哪走，可以参考这张地图。
| 阶段 | 我当时在做什么 | 如果你在这个阶段，可能会有这些感受 |
|---|---|---|
| Prompt阶段 | 在ChatBot对话框里优化指令，以为加了System Prompt就是”开发Agent” | 每次对话都从零开始，人变成了流程里的搬运工 |
| 低代码幻觉 | 折腾Coze/Dify，以为拖拉拽能绕过技术门槛 | 花80%时间学平台逻辑，产出极低，最后被平台逻辑困住 |
| 地图阶段 | 看懂LangChain/LangGraph架构，但造不出系统 | 你有一张地图，但不会开车，更多时间在查语法 |
| Vibe Coding阶段 | 从Cursor做粗糙产品，到Trae试图”开公司”，再到Claude Code提炼设计哲学 | 从”AI带你飞”到”剪不断理还乱”，再到”设计AI如何工作”——这段最长，也最难 |
没有标准路径，但有一些共通的东西：不管你在哪个阶段，底层能力始终是那三个——行业能力、AI认知、工程落地。
如果你也在走这条路，祝你好运。如果你发现了更好的路径，欢迎告诉我。
2026.04.05