本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

本作品 (李兆龙 博文, 由 李兆龙 创作)，由 李兆龙 确认，转载请注明版权。

引言

我一直挺喜欢尝试新工具，尤其是那些可能影响开发流程和工作方式的工具。AI 出现以后，我基本也是第一时间就开始用了。

最开始吸引我的原因其实很简单：我想知道它到底能做到什么程度。它到底只是一个更聪明的问答工具，还是一个能真正参与工作的助手？它到底适合拿来查资料、写代码、整理信息，还是更多停留在演示和试玩阶段？这些问题，比它热不热门更让我感兴趣。

所以过去这段时间里，我陆续试了不少 AI 相关的工具和用法，也一直在观察一件事：它到底能不能进入我的日常开发流程。

后来我发现，决定体验好坏的关键，往往不只在模型本身，而在于你怎么使用它、把它放在哪个环节，以及愿不愿意为了它调整原来的工作方式。回头看，这个过程并不是某一天突然变得特别顺手，而是我一点点摸到了它更适合发挥作用的位置。

这篇文章主要就是想把这个过程整理一下。不是想证明 AI 有多厉害，也不是想下什么结论，只是把我自己这段时间比较真实的使用路径记下来。

Chat-Bot

大多数人第一次接触 AI，基本都是从聊天界面开始的。

这种方式当然有价值。到现在为止，我还是会经常用聊天工具来做几类事情：快速了解一个陌生概念，帮忙理一下思路，验证一个方向是不是值得继续，或者把一些零散信息先收一收。

但如果要把它真正放进开发工作里，聊天框很快就会遇到明显的问题：你需要不断搬运上下文。

你要解释项目背景，复制文件内容，粘贴命令输出，补充目录结构，说明哪些建议已经试过，哪些做法在这个项目里不成立。很多时候，真正消耗精力的并不是“它给出的结果”，而是“为了让它理解问题，你额外做的那些准备工作”。

这也是为什么我后来慢慢觉得，聊天框更适合探索，不太适合承担正式的开发工作。它适合讨论，适合试探，适合快速来回，但一旦涉及真实项目，它就容易变成一个上下文靠手工搬运的临时窗口。

真正让我开始看到价值的，不是继续在聊天框里优化提问方式，而是开始使用那类能直接接触工作环境的工具。它们至少应该能读文件、执行命令、读取输出，最好还能调用一些外部能力，然后根据结果继续往下做。只有这样，它才不是一个单纯会回答的界面，而更像一个真的能参与任务推进的工具。

工作复现

真正让我开始学会怎么用它，是从一个很笨的方法开始的：拿那些我本来就会做的任务，让它重新做一遍。

不是把一个我自己也没想清楚的问题直接交给它，而是反过来，先挑那些我已经知道怎么做、也大概知道正确结果长什么样的工作，让它在合理提示下自己完成。说白了，就是用已经熟悉的任务去训练自己的判断，而不是拿陌生问题碰运气。

这个过程其实并不省时间。很多时候反而更费时间，因为等于同一类工作做了两次。自己先做一遍，再让它做一遍，然后对比结果、补约束、改提示、换拆分方式。

但也正是在这个阶段，我开始比较快地建立起一些比较稳定的判断。

首先，大任务不能直接丢。像把这个功能做完，把这个问题修掉这种说法，哪怕对碳基同事都不够清晰，对模型更是如此。把事情拆小，拆成边界明确、行动清楚的小任务，效果通常会稳定很多。

其次，模糊问题最好把想和做分开。先让它帮忙梳理方案、列出路径、比较取舍；等方案相对清楚了，再进入执行阶段。把规划和执行混在一起时，它很容易一边猜一边做，结果越走越偏，现在来看也就是plan mode。

还有一个后来越来越明显的点是：验证比提示更重要。

如果一个任务的结果没有办法验证，那它本质上就只能凭概率往前猜；但如果你给它测试、lint、构建输出、脚本检查、截图比对之类的反馈，它就有机会自己修正错误，TDD确实一个VibeCoding中极其有效的方式。

做多了之后，我对它的预期开始变得现实很多。不是它什么都能做，而是我逐渐知道了哪些任务它做得比较稳，哪些任务看上去能做其实很容易翻车，以及什么时候根本不该用它。

现在开发一个引擎内部的功能，再描述好需求后opus 4.6已经可以很好的完成功能，但是这是在需求极其明确的情况下，很多之前的经验还是会在这个过程中起到一些作用。

晚下班两小时的硅基员工

我大规模使用AI比较早，大概在2024年末，因为公司没有完善的报销机制，也没有现在这样对AI的态度如此火爆，所以Token还是有限制的，我基本控制在一个月自费$300左右，前后包含Clion、Windsurf、Github Coplit、Cursor、Claude、kimi、minimax、ChatGPT、Perplexity、Windsurf、Brave等软件的订阅费用。

后来因为公司的Token策略非常之财大气粗，各类加起来差不多没人每月$2500，而且前面的边界摸得差不多之后，我开始尝试另一种用法：不要只在我专心工作的时候用它，而是把它放到那些我本来就不太适合高效工作的时间段里。

比如一天快结束的时候，人通常已经有点疲劳了。这时候让我自己进入高强度开发状态，往往并不现实。但如果拿这段时间做一些启动成本高、但不一定需要我亲自盯着的事情，反而挺合适。

于是我慢慢养成了一个习惯：在一天的后半段，尤其是快收工的时候，把一些任务先交给它跑起来。

这类任务通常包括几种。

一种是做前置调研。比如去搜某类库、对比几个方案、整理一轮优缺点，把我第二天要看的材料先收齐。和古法调研的模式一样，这里最大的问题是没有办法确定已经调研完了全部我想要的知识源，本质还是部分私域的search源需要不停的手工去添加。

一种是做模糊方向的试探。并不是指望它直接产出可以上线的结果，而是先帮我把几个可能的实现路径摸一遍，看看会遇到哪些坑，哪里可能值得继续，比如这个Vibe出来的产品就是一个例子，可以一键在对应的产品上跑tsbs测试，现在压测目标都是用docker本地启动的，后续实际使用是换成云上产品就可以。

还有一种是做信息整理和初步筛选。比如把 issue、PR、待办上下文先拉平，做一个粗筛，让我第二天更快进入状态。

对我来说，这一步的意义不在于它替我完成了多少工作，而在于它把很多原本容易拖着不做的准备工作先推进了一点。真正省下来的，很多时候不是执行时间，而是启动成本，可以快速验证一些想法是否有效。

持续指导一个会犯错的硅基员工

再往后，我开始把一些任务真正交给它处理，但是一个问题会越来越明显：它会重复犯错。

有些错不是它不会，而是它总在同类地方出问题。比如跑错命令、找错入口、误解某个项目约定、在特定文件里做出不合适的修改。最开始的时候，我对这种事的反应通常是纠正它，然后继续下一轮。但后来我越来越觉得，这种做法其实很浪费。

更值得做的事是：不要只改这一次，而要想办法让它下次别再犯同样的错。

这部分对我触动很大，因为它其实和工程实践本身没什么区别。

如果某类错误经常出现，那说明它不应该继续依赖口头提醒，而应该变成规则、脚本或者检查流程。把项目约定写清楚，把常用命令固定下来，把关键步骤补上测试，把格式要求做成校验，把容易出错的地方变成自动检查，全部沉淀为Rules

这样做之后，变化并不是模型突然聪明了，而是整个协作环境更稳了。

我现在越来越把这件事理解成：使用 AI，不只是学会怎么提问，而是在借这个机会重新整理自己的工程环境。很多原来只存在于脑子里的经验，最后都值得写下来；很多原来靠人盯的流程，最后也值得变成可以验证的步骤。AI 在这里更像一个放大器：它会把流程里的模糊地带暴露出来，也逼着你把模糊的地方补清楚。

7*24 硅基团队

到最近这段时间，我对它的使用方式又有了一个比较明显的变化：我会更频繁地问自己一件事——现在是不是有一部分工作和事务，其实交给AI管理？

AIops就是一个很好的实践的例子，痛点在因为组织结构的变动，团队的人数暂时变少，而且之前经验沉淀不足，依赖专家经验，新同学没办法快速接入，运营上花费了很多时间，而且导致上下文频繁被打断。

这里设计并实现了一套AIops系统，在告警、工单、问答中先使用AI分析，逐步迭代提升准确度，整个过程模拟人类排查问题的过程，虽然目前准确性没有那么高，但是再有一段时间的打磨，预期可以达到80%以上，而且这反推我们去优化可观测性和知识体系的沉淀。

在个人方面，很多的想法可以持续验证并打通全流程，团队有同学做的量化分析就是一个很好的学习例子。我自己来讲可以基于TDD去直接开发一些之前想做而又没有时间做的事情，比如开源协议的接入，部分模块、举另外一个例子，知乎因为问答社区的平台定位原因，回答推流比文章高很多，我做了一个知乎自动回答的平台，在邀请回答、知乎热榜、大家都在答模块等自动基于claude 4.6opus回答，当然为了平台内容质量，现阶段只是自动放进草稿箱。

这里其实看X平台上有很多实践的例子，比如polymarket套利，因子发掘，时序分析等已经有很多人实践有效了

工作边界全栈融合

[4]传统的产品管理模式基于这样的假设：项目开始时的技术可行性与项目结束时的技术可行性大致相同。产品经理会在项目初期收集足够的信息，以便对未来做出有把握的预测，然后按照计划执行，历时数月。

指数级改进的模型打破了这一假设。你当初设计时所依据的约束条件可能会在项目进行到一半时消失，团队需要根据这一现实进行调整。新的产品管理节奏是快速实验、持续发布，以及对有效方法的持续投入。

你在一块正在上升的地面上盖房子。

以前的核心交付是文档：PRD、需求说明、流程图。

现在的核心交付变成了两样东西：可运行的原型和可衡量的 eval。

由于模型能力的逐步演化，[4]中的观点是团队的角色正在融合：设计师负责代码交付，工程师负责产品决策，产品经理负责构建原型和评估。这种模式之所以行之有效，是因为清晰的战略和目标让每个人都能自主地确定优先级。产品经理的职责是厘清快速发展的模型带来的不确定性，推动团队拓展思维，思考各种可能性，并扫清障碍，加快产品交付速度。

我们团队是一个小而美的团队，Leader定大方向，研发负责产品排期、研发、测试与质量、运营全流程建设，一个如此庞大的项目在非AI时代这是不可想象的，这也侧面要求个人的技能跨域多个职位。

我想这也是当下各类平台上看到的焦虑所在，在新兴市场吸收工作岗位前，个人效率提升10倍以上，势必造成暂时性工作岗位的减少，如果人类体量不能上升一个数量级，那带来的就是结构性失业，自然这其中也蕴含着无数机会。

结束语

作为一个存储相关从业者，最看重的事情始终是质量，质量的衡量明面上可以用覆盖率、故障数、演习数来衡量，但是落到个人身上，现阶段产品质量和注意力息息相关，如果个人承担的事务过于多，用于质量的注意力就会减少。
后续招到新人，我想也先会把培养的中心放在质量建设上，这也是我认为当前的个人核心竞争力之一，虽然相对难量化。

屠龙勇士终成恶龙

参考：

1. Cat Wu 推文
2. Product management on the AI exponential
3. My AI Adoption Journey
4. Anthropic 产品经理：PRD 已死，原型万岁
5. Building Effective AI Agents: Architecture Patterns and Implementation Frameworks