线下技术活动参加得多了能让人全程放下手机、结束后还忍不住在备忘录里敲下几百字感想的场子其实不多。前阵子去了一场在北京办的开发者线下交流活动主办方是一款叫 TRAE 的 AI 编程工具团队主题围绕 AI 辅助开发的实际落地展开。去之前我的预期很朴素——无非是产品宣讲加几个 Demo中间穿插几页 PPT散场领个周边。结果两个多小时坐下来中途我一次都没摸手机散场后还跟旁边两位做后端的哥们儿在门口聊了二十分钟。这篇就把我看到的、听到的、以及自己回来之后动手验证的东西完整复盘一遍重点不在活动好不好而在于这场活动里透出来的 AI 编程工具的真实使用状态以及普通开发者能从中拿走什么。如果你正在纠结要不要把 AI 编程工具真正纳入日常工作流或者已经装了但只用它写写注释和单元测试那这篇值得往下看。我会把现场演示里那些看起来很简单但自己一上手就翻车的细节拆开讲也会说说我在自己项目里复现时踩到的坑。全程不吹不黑只讲我亲眼看到和亲手验证过的东西。1. 这场活动到底讲了什么从能写代码到能干活的认知切换1.1 现场演示的第一个反常识点不追求一次生成正确大部分人对 AI 编程工具的想象是我说需求它吐代码我复制粘贴。现场第一个演示就把这个预期打碎了。演示者给了一个带明确业务约束的需求——大概是一个带分页和筛选的数据列表接口——然后故意让工具先生成一版能跑但不够好的实现接着通过连续几轮对话去调整先补边界条件再改查询效率最后加错误处理。这个流程看起来啰嗦但它传递的信号很明确AI 编程工具的价值不在一次成型而在缩短迭代回路。传统写法里你改一版要重新读代码、定位、改、跑测试一轮下来十几分钟对话式迭代里一轮可能就一两分钟。演示者现场统计了一下同一个需求从零到可用对话式迭代走了六轮总耗时不到十二分钟。这个数字未必适用于所有场景但方向是对的——把工具当成一个反应很快但需要你把关的初级搭档而不是一次交付的外包。我在自己项目里复现这个思路时最大的感受是心态要先调整。一开始我总想着把提示词写得完美无缺结果反而卡在措辞上。后来改成先让它出一版粗糙的我再基于结果提修改意见效率明显上来了。这个转变听着简单但真要做到需要克服一种怕它写错的心理障碍。1.2 演示里被反复强调的一件事上下文给得越具体返工越少现场有个细节我印象很深。演示者在提需求时会主动把相关的数据结构、已有的工具函数名、甚至项目里约定的命名风格都贴进去。他原话大意是你不告诉它你项目里已经有什么它就会自己造一套最后你还得改。这句话戳中了很多人的痛点。我见过不少同事用 AI 工具时只丢一句帮我写个用户登录接口然后抱怨生成的东西跟项目风格完全不搭。问题不在工具在于上下文缺失。现场演示里同一个需求给足上下文和只给一句话生成结果的可用率差距非常明显——前者基本改两处就能用后者几乎要重写。这里有个实操层面的经验把项目里常用的类型定义、工具函数、目录结构整理成一个可以快速粘贴的上下文片段用的时候直接带上。这个动作前期花半小时后面每次对话都能省下大量返工时间。我在自己的项目里建了一个context.md里面放了核心数据模型和几个高频工具函数的签名用的时候整段贴进去效果立竿见影。1.3 现场观众提问暴露的真实焦虑问答环节比演示环节更有信息量。有人问生成代码的准确性怎么保证有人问团队里怎么统一使用规范还有人直接问这东西会不会让初级开发者失去成长机会。这些问题背后其实是同一个焦虑工具变强了人的位置在哪。现场的回答我不完全记得原话但核心逻辑是工具负责从零到一的体力活人负责从一到好的判断活。这个分工在演示里体现得很清楚——工具生成的代码从来不是直接上线的中间必然经过人的审查、调整、测试。换句话说审查能力和判断能力反而变得更重要了。你越懂代码越能看出生成结果哪里有问题工具对你的增益就越大你越不懂越容易被看起来能跑的代码骗过去。这个结论对我触动挺大。它意味着 AI 编程工具不是降低门槛这么简单而是把门槛从会写挪到了会看。对有一定基础的开发者是放大器对完全零基础的人是双刃剑。2. 现场演示拆解一个真实需求是怎么被对话出来的2.1 需求描述阶段把模糊需求翻译成可执行约束演示用的需求本身不复杂但演示者的描述方式值得学。他没有说帮我写个列表接口而是拆成了几层数据从哪来、分页参数叫什么、筛选条件有哪几个、返回结构长什么样、异常情况怎么处理。这种拆法本质上是在替工具做需求分析。我后来在自己的项目里试了一次把帮我写个文件上传功能拆成上传大小限制、允许的扩展名、存储路径规则、失败重试逻辑、返回给前端的字段。拆完之后再提需求生成结果的完整度明显高一个档次。原因很简单——模糊的需求只能得到模糊的代码而模糊的代码返工成本最高。这里有个容易被忽略的点拆需求的过程本身就是在梳理自己的思路。很多时候我们以为自己想清楚了一动笔拆就发现有几个边界条件根本没考虑。所以这个动作不只是为了 AI对自己也是有好处的。2.2 迭代调整阶段怎么提修改意见才有效演示里最精彩的部分是迭代。第一版生成后演示者没有推倒重来而是针对性地提了三条修改意见查询条件加上索引提示、分页参数做合法性校验、异常返回统一格式。每一条都很具体指向明确。对比一下常见的无效提法这段代码不太好优化一下——这种话工具只能瞎猜。有效的提法是这个查询在数据量大时会慢帮我把筛选字段的查询改成先走索引再过滤。修改意见的质量直接决定迭代轮数。我在复现时总结了一个小规律提修改意见时尽量带上为什么。比如不说加个校验而说这个参数来自前端可能传空加个非空校验并返回明确错误码。带上原因之后生成结果往往一次到位因为工具能理解你的意图而不是机械执行。2.3 收尾验证阶段演示者坚持做的两件事演示结束前演示者做了两个动作我觉得是整场最值得抄的作业。第一他把生成的代码逐行过了一遍边过边解释每一段在干什么第二他跑了一遍已有的测试用例确认没有破坏原有功能。这两件事听着是常识但实际使用中很多人会跳过。尤其是第二件——AI 生成的代码最容易出问题的地方不是新功能本身而是它对已有代码的顺手改动。演示者特意提到工具在实现新功能时可能会调整相邻的函数这些调整未必符合你的预期必须靠测试兜底。我在自己项目里就吃过这个亏。有一次让工具加一个功能它顺手把一个公共工具函数的返回值结构改了导致另一个模块静默出错直到两天后才发现。从那以后我养成了一个习惯AI 参与的改动提交前必须跑全量测试没有测试覆盖的模块手动过一遍调用方。3. 回来之后我自己复现时踩的坑3.1 坑一上下文贴太多反而干扰判断现场看演示时觉得上下文给足是万能药自己上手才发现有度的问题。我第一次复现时把整个数据模型文件几百行全贴进去了结果工具在生成时引用了一堆跟当前需求无关的字段代码变得臃肿。后来改成只贴当前需求直接相关的部分情况立刻好转。这个经验说明一件事上下文不是越多越好而是越相关越好。判断标准很简单——这段信息如果不给工具会不会猜错会就给不会就别塞。塞多了不仅干扰工具也干扰你自己审查时的注意力。3.2 坑二过度信任看起来能跑的代码有一次生成的一段逻辑语法没问题跑起来也不报错但业务语义是错的——它把已删除的记录也算进了统计里。这种错误最危险因为测试如果只测能不能跑通根本发现不了。现场演示里演示者反复强调逐行过一遍当时我觉得有点小题大做踩了这个坑之后才明白他的用意。AI 生成的代码在语法层面通常很干净问题往往藏在业务语义里。所以审查的重点不该是有没有语法错误而应该是这段逻辑符不符合业务规则。这个视角的切换很关键。3.3 坑三对话轮数多了之后上下文漂移长对话有个隐蔽的问题聊到后面工具对前面约定的理解会漂移。我复现时聊了七八轮突然发现它把最早约定的返回格式改了而且改得毫无征兆。回头翻对话才发现中间某一轮我提了个新需求它顺手把返回结构优化了。应对办法有两个一是关键约定在每轮对话里重复强调比如返回结构保持之前约定的{code, data, msg}不变二是长任务拆成短对话一个对话只解决一个子问题解决完把结果固化下来再开新对话。后者更彻底我现在基本都用这个方式。4. 从这场活动看 AI 编程工具的真实定位4.1 它擅长什么有明确边界的体力活综合现场演示和我自己的复现这类工具目前最稳的场景是有明确输入输出、有现成模式可循的任务写 CRUD 接口、补单元测试、写数据转换脚本、改配置、生成样板代码。这些任务的共同点是边界清晰、对错可验证工具出错你也能很快发现。反过来涉及架构决策、复杂业务规则、跨模块重构的任务工具目前还只能打辅助。现场演示者也很坦诚说这类任务他们内部也是人来主导工具负责查资料、出草稿、做对比。4.2 它不擅长什么需要全局判断的活有个观众问得好能不能让它直接重构整个模块现场的回答大意是小范围可以大范围不建议因为工具看不到你项目里的隐性约定——哪些函数不能动、哪些依赖有历史包袱、哪些地方有性能红线。这些信息不在代码里在人脑子里。这个边界感很重要。把工具用在它擅长的区间收益最大越界使用返工成本可能超过自己写。我在项目里划了条线单文件、单函数级别的改动放心交给工具跨三个以上文件的改动工具只用来出方案参考落地还是自己来。4.3 对团队协作的影响规范变得更重要了活动里有个话题没展开但很值得想团队里多人用 AI 工具怎么保证风格统一现场提了一句靠规范约束但具体怎么做没细说。我自己的做法是把团队规范写成工具能读的上下文——命名约定、目录结构、错误码规范整理成文档用的时候带上。这样生成结果至少在大方向上跟团队一致减少后期统一风格的成本。这件事的深层含义是AI 工具放大了规范的价值。以前规范靠 code review 兜底现在规范可以直接喂给工具从源头减少偏差。规范写得越清楚工具产出越稳定这个正循环挺有意思。5. 如果你也想把这类工具用起来一份可落地的上手清单5.1 第一周先建立上下文素材库别急着让工具写复杂功能。第一周就做一件事把项目里的核心数据模型、高频工具函数、命名约定、目录结构整理成几个可以快速粘贴的片段。这个动作看着枯燥但它是后面所有高效使用的基础。我当时的做法是建一个ai-context目录按数据模型工具函数规范约定分三个文件用的时候按需拼接。5.2 第二周从低风险高频率的任务切入选那些出错也容易发现的任务练手写单元测试、写数据转换脚本、补注释、生成样板代码。这些任务的特点是对错可验证适合建立对工具的手感——你会逐渐摸清它在什么情况下靠谱、什么情况下会翻车。这个手感比任何教程都值钱。5.3 第三周起建立生成-审查-测试的固定流程到这一阶段重点不是怎么让它写得更好而是怎么保证它写的东西不出事。固定流程建议是生成后逐行审查业务语义、跑全量测试、检查它对相邻代码的改动、关键约定在对话中重复确认。这四步走完基本能把风险压到可控范围。提示审查时重点看业务语义而不是语法正确。AI 生成的代码语法通常很干净坑往往埋在业务规则的理解偏差里。5.4 一个容易被忽略的细节保存好用的对话遇到一次特别顺的对话别关掉就完事。把那次对话里的提示词结构、上下文组织方式记下来形成自己的提示模板。我目前攒了五六个模板覆盖接口开发、测试生成、脚本编写几个高频场景用的时候改改具体需求就能上省下大量组织语言的时间。6. 现场之外几个我自己的使用心得6.1 把它当结对搭档而不是代码生成器心态上的差别会体现在用法上。当生成器用你会追求一次给对当搭档用你会自然地进入讨论-调整的节奏。后者更接近这类工具的设计初衷实际效率也更高。我现在提需求时会像跟同事说话一样先交代背景再说目标最后说约束生成结果的可用率比早期高出一大截。6.2 别让它替你做要不要做的决定工具很擅长回答怎么做但不擅长回答要不要做。架构选型、技术方案取舍、优先级排序这些事还是得自己判断。现场演示里演示者从头到尾都在做决策——哪版能用、哪里要改、什么时候停——工具只是执行。这个主次关系不能反。6.3 定期回看生成记录能发现自己的思维盲区我有个习惯每隔一段时间翻翻自己跟工具的对话记录。翻的时候会发现一些有意思的东西某些需求我描述得特别含糊说明那块业务我自己也没想清楚某些修改意见反复出现说明那类问题是我的固定盲区。这种反向复盘挺有价值比单纯看代码 review 记录更能暴露思维层面的问题。那场活动散场时天已经黑了门口几个参会的人还在讨论刚才的演示。我走在路上想的是这类工具真正改变的不是写代码的速度而是写代码之前的思考方式——你得先把需求想清楚、把上下文备齐、把验收标准定好工具才能帮上忙。这个前置成本省不掉省了就会在后面以返工的形式还回来。想明白这一点比学会任何提示词技巧都管用。
线下技术活动参加得多了能让人全程放下手机、结束后还忍不住在备忘录里敲下几百字感想的场子其实不多。前阵子去了一场在北京办的开发者线下交流活动主办方是一款叫 TRAE 的 AI 编程工具团队主题围绕 AI 辅助开发的实际落地展开。去之前我的预期很朴素——无非是产品宣讲加几个 Demo中间穿插几页 PPT散场领个周边。结果两个多小时坐下来中途我一次都没摸手机散场后还跟旁边两位做后端的哥们儿在门口聊了二十分钟。这篇就把我看到的、听到的、以及自己回来之后动手验证的东西完整复盘一遍重点不在活动好不好而在于这场活动里透出来的 AI 编程工具的真实使用状态以及普通开发者能从中拿走什么。如果你正在纠结要不要把 AI 编程工具真正纳入日常工作流或者已经装了但只用它写写注释和单元测试那这篇值得往下看。我会把现场演示里那些看起来很简单但自己一上手就翻车的细节拆开讲也会说说我在自己项目里复现时踩到的坑。全程不吹不黑只讲我亲眼看到和亲手验证过的东西。1. 这场活动到底讲了什么从能写代码到能干活的认知切换1.1 现场演示的第一个反常识点不追求一次生成正确大部分人对 AI 编程工具的想象是我说需求它吐代码我复制粘贴。现场第一个演示就把这个预期打碎了。演示者给了一个带明确业务约束的需求——大概是一个带分页和筛选的数据列表接口——然后故意让工具先生成一版能跑但不够好的实现接着通过连续几轮对话去调整先补边界条件再改查询效率最后加错误处理。这个流程看起来啰嗦但它传递的信号很明确AI 编程工具的价值不在一次成型而在缩短迭代回路。传统写法里你改一版要重新读代码、定位、改、跑测试一轮下来十几分钟对话式迭代里一轮可能就一两分钟。演示者现场统计了一下同一个需求从零到可用对话式迭代走了六轮总耗时不到十二分钟。这个数字未必适用于所有场景但方向是对的——把工具当成一个反应很快但需要你把关的初级搭档而不是一次交付的外包。我在自己项目里复现这个思路时最大的感受是心态要先调整。一开始我总想着把提示词写得完美无缺结果反而卡在措辞上。后来改成先让它出一版粗糙的我再基于结果提修改意见效率明显上来了。这个转变听着简单但真要做到需要克服一种怕它写错的心理障碍。1.2 演示里被反复强调的一件事上下文给得越具体返工越少现场有个细节我印象很深。演示者在提需求时会主动把相关的数据结构、已有的工具函数名、甚至项目里约定的命名风格都贴进去。他原话大意是你不告诉它你项目里已经有什么它就会自己造一套最后你还得改。这句话戳中了很多人的痛点。我见过不少同事用 AI 工具时只丢一句帮我写个用户登录接口然后抱怨生成的东西跟项目风格完全不搭。问题不在工具在于上下文缺失。现场演示里同一个需求给足上下文和只给一句话生成结果的可用率差距非常明显——前者基本改两处就能用后者几乎要重写。这里有个实操层面的经验把项目里常用的类型定义、工具函数、目录结构整理成一个可以快速粘贴的上下文片段用的时候直接带上。这个动作前期花半小时后面每次对话都能省下大量返工时间。我在自己的项目里建了一个context.md里面放了核心数据模型和几个高频工具函数的签名用的时候整段贴进去效果立竿见影。1.3 现场观众提问暴露的真实焦虑问答环节比演示环节更有信息量。有人问生成代码的准确性怎么保证有人问团队里怎么统一使用规范还有人直接问这东西会不会让初级开发者失去成长机会。这些问题背后其实是同一个焦虑工具变强了人的位置在哪。现场的回答我不完全记得原话但核心逻辑是工具负责从零到一的体力活人负责从一到好的判断活。这个分工在演示里体现得很清楚——工具生成的代码从来不是直接上线的中间必然经过人的审查、调整、测试。换句话说审查能力和判断能力反而变得更重要了。你越懂代码越能看出生成结果哪里有问题工具对你的增益就越大你越不懂越容易被看起来能跑的代码骗过去。这个结论对我触动挺大。它意味着 AI 编程工具不是降低门槛这么简单而是把门槛从会写挪到了会看。对有一定基础的开发者是放大器对完全零基础的人是双刃剑。2. 现场演示拆解一个真实需求是怎么被对话出来的2.1 需求描述阶段把模糊需求翻译成可执行约束演示用的需求本身不复杂但演示者的描述方式值得学。他没有说帮我写个列表接口而是拆成了几层数据从哪来、分页参数叫什么、筛选条件有哪几个、返回结构长什么样、异常情况怎么处理。这种拆法本质上是在替工具做需求分析。我后来在自己的项目里试了一次把帮我写个文件上传功能拆成上传大小限制、允许的扩展名、存储路径规则、失败重试逻辑、返回给前端的字段。拆完之后再提需求生成结果的完整度明显高一个档次。原因很简单——模糊的需求只能得到模糊的代码而模糊的代码返工成本最高。这里有个容易被忽略的点拆需求的过程本身就是在梳理自己的思路。很多时候我们以为自己想清楚了一动笔拆就发现有几个边界条件根本没考虑。所以这个动作不只是为了 AI对自己也是有好处的。2.2 迭代调整阶段怎么提修改意见才有效演示里最精彩的部分是迭代。第一版生成后演示者没有推倒重来而是针对性地提了三条修改意见查询条件加上索引提示、分页参数做合法性校验、异常返回统一格式。每一条都很具体指向明确。对比一下常见的无效提法这段代码不太好优化一下——这种话工具只能瞎猜。有效的提法是这个查询在数据量大时会慢帮我把筛选字段的查询改成先走索引再过滤。修改意见的质量直接决定迭代轮数。我在复现时总结了一个小规律提修改意见时尽量带上为什么。比如不说加个校验而说这个参数来自前端可能传空加个非空校验并返回明确错误码。带上原因之后生成结果往往一次到位因为工具能理解你的意图而不是机械执行。2.3 收尾验证阶段演示者坚持做的两件事演示结束前演示者做了两个动作我觉得是整场最值得抄的作业。第一他把生成的代码逐行过了一遍边过边解释每一段在干什么第二他跑了一遍已有的测试用例确认没有破坏原有功能。这两件事听着是常识但实际使用中很多人会跳过。尤其是第二件——AI 生成的代码最容易出问题的地方不是新功能本身而是它对已有代码的顺手改动。演示者特意提到工具在实现新功能时可能会调整相邻的函数这些调整未必符合你的预期必须靠测试兜底。我在自己项目里就吃过这个亏。有一次让工具加一个功能它顺手把一个公共工具函数的返回值结构改了导致另一个模块静默出错直到两天后才发现。从那以后我养成了一个习惯AI 参与的改动提交前必须跑全量测试没有测试覆盖的模块手动过一遍调用方。3. 回来之后我自己复现时踩的坑3.1 坑一上下文贴太多反而干扰判断现场看演示时觉得上下文给足是万能药自己上手才发现有度的问题。我第一次复现时把整个数据模型文件几百行全贴进去了结果工具在生成时引用了一堆跟当前需求无关的字段代码变得臃肿。后来改成只贴当前需求直接相关的部分情况立刻好转。这个经验说明一件事上下文不是越多越好而是越相关越好。判断标准很简单——这段信息如果不给工具会不会猜错会就给不会就别塞。塞多了不仅干扰工具也干扰你自己审查时的注意力。3.2 坑二过度信任看起来能跑的代码有一次生成的一段逻辑语法没问题跑起来也不报错但业务语义是错的——它把已删除的记录也算进了统计里。这种错误最危险因为测试如果只测能不能跑通根本发现不了。现场演示里演示者反复强调逐行过一遍当时我觉得有点小题大做踩了这个坑之后才明白他的用意。AI 生成的代码在语法层面通常很干净问题往往藏在业务语义里。所以审查的重点不该是有没有语法错误而应该是这段逻辑符不符合业务规则。这个视角的切换很关键。3.3 坑三对话轮数多了之后上下文漂移长对话有个隐蔽的问题聊到后面工具对前面约定的理解会漂移。我复现时聊了七八轮突然发现它把最早约定的返回格式改了而且改得毫无征兆。回头翻对话才发现中间某一轮我提了个新需求它顺手把返回结构优化了。应对办法有两个一是关键约定在每轮对话里重复强调比如返回结构保持之前约定的{code, data, msg}不变二是长任务拆成短对话一个对话只解决一个子问题解决完把结果固化下来再开新对话。后者更彻底我现在基本都用这个方式。4. 从这场活动看 AI 编程工具的真实定位4.1 它擅长什么有明确边界的体力活综合现场演示和我自己的复现这类工具目前最稳的场景是有明确输入输出、有现成模式可循的任务写 CRUD 接口、补单元测试、写数据转换脚本、改配置、生成样板代码。这些任务的共同点是边界清晰、对错可验证工具出错你也能很快发现。反过来涉及架构决策、复杂业务规则、跨模块重构的任务工具目前还只能打辅助。现场演示者也很坦诚说这类任务他们内部也是人来主导工具负责查资料、出草稿、做对比。4.2 它不擅长什么需要全局判断的活有个观众问得好能不能让它直接重构整个模块现场的回答大意是小范围可以大范围不建议因为工具看不到你项目里的隐性约定——哪些函数不能动、哪些依赖有历史包袱、哪些地方有性能红线。这些信息不在代码里在人脑子里。这个边界感很重要。把工具用在它擅长的区间收益最大越界使用返工成本可能超过自己写。我在项目里划了条线单文件、单函数级别的改动放心交给工具跨三个以上文件的改动工具只用来出方案参考落地还是自己来。4.3 对团队协作的影响规范变得更重要了活动里有个话题没展开但很值得想团队里多人用 AI 工具怎么保证风格统一现场提了一句靠规范约束但具体怎么做没细说。我自己的做法是把团队规范写成工具能读的上下文——命名约定、目录结构、错误码规范整理成文档用的时候带上。这样生成结果至少在大方向上跟团队一致减少后期统一风格的成本。这件事的深层含义是AI 工具放大了规范的价值。以前规范靠 code review 兜底现在规范可以直接喂给工具从源头减少偏差。规范写得越清楚工具产出越稳定这个正循环挺有意思。5. 如果你也想把这类工具用起来一份可落地的上手清单5.1 第一周先建立上下文素材库别急着让工具写复杂功能。第一周就做一件事把项目里的核心数据模型、高频工具函数、命名约定、目录结构整理成几个可以快速粘贴的片段。这个动作看着枯燥但它是后面所有高效使用的基础。我当时的做法是建一个ai-context目录按数据模型工具函数规范约定分三个文件用的时候按需拼接。5.2 第二周从低风险高频率的任务切入选那些出错也容易发现的任务练手写单元测试、写数据转换脚本、补注释、生成样板代码。这些任务的特点是对错可验证适合建立对工具的手感——你会逐渐摸清它在什么情况下靠谱、什么情况下会翻车。这个手感比任何教程都值钱。5.3 第三周起建立生成-审查-测试的固定流程到这一阶段重点不是怎么让它写得更好而是怎么保证它写的东西不出事。固定流程建议是生成后逐行审查业务语义、跑全量测试、检查它对相邻代码的改动、关键约定在对话中重复确认。这四步走完基本能把风险压到可控范围。提示审查时重点看业务语义而不是语法正确。AI 生成的代码语法通常很干净坑往往埋在业务规则的理解偏差里。5.4 一个容易被忽略的细节保存好用的对话遇到一次特别顺的对话别关掉就完事。把那次对话里的提示词结构、上下文组织方式记下来形成自己的提示模板。我目前攒了五六个模板覆盖接口开发、测试生成、脚本编写几个高频场景用的时候改改具体需求就能上省下大量组织语言的时间。6. 现场之外几个我自己的使用心得6.1 把它当结对搭档而不是代码生成器心态上的差别会体现在用法上。当生成器用你会追求一次给对当搭档用你会自然地进入讨论-调整的节奏。后者更接近这类工具的设计初衷实际效率也更高。我现在提需求时会像跟同事说话一样先交代背景再说目标最后说约束生成结果的可用率比早期高出一大截。6.2 别让它替你做要不要做的决定工具很擅长回答怎么做但不擅长回答要不要做。架构选型、技术方案取舍、优先级排序这些事还是得自己判断。现场演示里演示者从头到尾都在做决策——哪版能用、哪里要改、什么时候停——工具只是执行。这个主次关系不能反。6.3 定期回看生成记录能发现自己的思维盲区我有个习惯每隔一段时间翻翻自己跟工具的对话记录。翻的时候会发现一些有意思的东西某些需求我描述得特别含糊说明那块业务我自己也没想清楚某些修改意见反复出现说明那类问题是我的固定盲区。这种反向复盘挺有价值比单纯看代码 review 记录更能暴露思维层面的问题。那场活动散场时天已经黑了门口几个参会的人还在讨论刚才的演示。我走在路上想的是这类工具真正改变的不是写代码的速度而是写代码之前的思考方式——你得先把需求想清楚、把上下文备齐、把验收标准定好工具才能帮上忙。这个前置成本省不掉省了就会在后面以返工的形式还回来。想明白这一点比学会任何提示词技巧都管用。
