分类目录归档:架构和远方

AI 时代研发同学的必备软技能:从「写好代码」到「终结问题」的进化指南

当 Cursor/Windsurf 为你生成代码片段,ChatGPT/DeepSeek 为你优化技术文档,Midjourney 为你绘制精美草图,你是否也曾思考过:
「在这个 AI 时代,你工作的核心竞争力究竟是什么?」

过去,技术硬实力是研发同学的核心武器,但今天,AI 工具正在以惊人的速度让这些技能「平民化」:

  • 代码量产:AI 几秒钟生成数百行代码;
  • 自动调优:AI 自主优化算法参数,超越人类水平;
  • 全栈覆盖:从前端到后端,从 DevOps 到数据分析,AI 工具无处不在。

然而,AI 的快速普及并不是威胁,而是机会。未来最优秀的研发,不再只是写代码的人,而是能够驾驭 AI,解决复杂问题、创造价值的人。而这一切的基础,就在于软技能的升级。

1. AI 时代的「新研发」画像:从执行到创造的转型

AI 时代对研发同学的要求正在发生质的变化。你需要的不仅是工具使用能力,更是掌握以下三大能力的思维跃迁:

1.1 问题定义力:从「如何做」到「做什么」

AI 工具可以为你提供实现方案,但它无法回答「我们到底要解决什么问题」。能精准定义问题的人,才能引领 AI 高效运转。

  • 举例:用户反馈「系统太慢」,真正的瓶颈可能并不是代码性能,而是业务逻辑过于复杂,或者数据库架构不合理。
  • 关键问题:AI 可以帮你解决「已知问题」,但只有你能找到「未知问题」。

建议实践:

  • 在接到需求时,不急于动手写代码,而是花 30% 的时间明确核心目标。
  • 使用「5 WHY」拆解问题,找到真正的根因。

以某电商大促系统卡顿的问题为例:

当用户反馈「下单页面卡顿」时,我们需要问:

第一层追问:卡顿发生在点击下单按钮时?还是页面加载时?(发生在哪里?)

第二层追问:只有大促期间出现?普通时段正常?(发生在什么时候?)

第三层拆解:日志显示数据库查询耗时暴增,但真的是 SQL 问题吗?(多问一次)

最终发现根本原因是优惠券叠加计算逻辑:当用户同时使用店铺券、平台券、满减券时,业务逻辑循环嵌套导致指数级复杂度上升。

  • 用「5 WHY」法拆解问题
    比如面对「系统太慢」的反馈,可以问:
    1. 为什么太慢? -> 数据查询耗时过长。
    2. 为什么查询耗时过长? -> 数据库没有索引。
    3. 为什么没有索引? -> 设计时没有考虑这个场景。
      通过层层追问,找到问题的根因,而不是停留在表面。

多站在用户视角思考:系统性能对用户真正的影响是什么?是加载时间?响应速度?还是页面卡顿?明确目标后再行动。

1.2 跨领域协作力:从「技术孤岛」到「多维桥梁」

研发同学往往被视为技术专家,但在 AI 时代,研发工作正在从「单一技术领域」走向「跨领域协作」,能够在技术与业务、技术与设计之间建立桥梁的人更具影响力

AI 工具的普及,让技术不再是只有工程师能看懂的「黑箱」,它正在成为每个部门都能触及的工具。这意味着,研发者的作用不再是单纯的技术专家,而是跨部门桥梁

  • 场景 1:向业务团队解释 AI 模型的局限性,例如:大模型生成的预测结果为何在特定场景无法应用。
  • 场景 2:与设计师协作,优化用户体验,而不是单纯关注技术实现。

建议实践:

  • 多关注非技术领域的语言和逻辑,例如:用「用户故事」代替技术术语。
  • 在技术方案中,明确描述其对业务的价值和风险。

举个例子:从「技术术语」到「用户故事」假设业务部门提出一个需求:「我们需要一个 AI 模型来预测用户流失率。」

  • 如果你直接给出技术方案,比如「我们用随机森林算法和 LSTM 模型」,业务团队可能一头雾水,也无法判断你的方案是否符合实际需求。
  • 更好的方式是转化为业务语言,比如:「我们会用 AI 模型预测哪些用户可能流失,这样可以提醒销售团队提前联系,并减少用户流失。」

这种「跨领域翻译能力」不仅能让技术方案更落地,还能让你在团队中更具影响力。

那么,如何提升跨领域协作力?

  • 学习对方的语言和逻辑:比如了解产品经理常用的「用户故事」格式,用场景化的方式描述技术方案。
    • 比如:用户故事可以是「作为一名用户,我希望系统能在 2 秒内加载完成,这样我就不会失去耐心」。
  • 明确技术对业务的价值:在提交技术方案时,补充说明「这个功能可以提升 xx% 的用户体验,节约 xx% 的成本」。

在 AI 时代,研发者不仅是技术的推动者,更是沟通技术与业务、技术与设计的桥梁。谁能打通这些边界,谁就掌握了更多主动权。

1.3 批判性思维:从「接受答案」到「验证答案」

AI 工具给出的代码、方案并非总是可靠。研发者必须具备质疑与验证的能力,避免高效地犯错。

  • AI 提供的代码是否安全? Cursor 生成的代码可能存在漏洞。
  • AI 生成的方案是否符合需求场景? 自动化工具可能忽略了业务逻辑中的特殊条件。

建议实践:

  • 为你的 AI 工作流创建「质检清单」,例如:性能测试、安全检查、业务逻辑验证等。
  • 从 AI 输出中学习,而不是无脑接受,学习其思路和编码的方式等等。

如何培养批判性思维?

  • 为 AI 创建「质检清单」
    每次接受 AI 的输出前,进行以下检查:

    1. 技术层面:代码是否经过边界测试?是否存在安全隐患?
    2. 业务层面:输出结果是否符合实际场景?是否考虑了用户行为习惯?
    3. 合规层面:生成内容是否符合公司政策或行业法规?
  • 从失败案例中学习:多分析 AI 工具失败的案例,理解 AI 的局限性和潜在风险。比如,研究某些场景下的 AI 偏见问题,避免类似错误。

2. AI 时代的软技能到底有多重要?

如果技术硬实力是「上限」,软技能就是「下限」。AI 可以让所有人起点更高,但也会放大研发者的短板:

  • 不会定义问题的人,会被工具束缚在错误的方向上。
  • 缺乏沟通能力的人,会在跨部门协作中失去对话权。
  • 思维固化的人,无法适应 AI 工具带来的工作流变化。

2.1 生存指南

  1. 用「 CTO 思维」拆需求,接到任务时先问三连:

    1. 这个需求背后的商业目标是什么?(比如提升转化率?降低客诉?)
    2. 如果只能用一句话描述成功标准,应该是什么?
    3. 现有数据中哪些指标暗示了真正的问题?(如支付环节跳出率>80%)
  2. 给 AI 加「导航仪」,向 AI 提问时避免开放式指令,而是结构化引导:

    • 错误示范:”优化系统性能”
    • 正确姿势:”当前订单提交平均耗时 2.3 秒( APM 数据),在保证 100% 数据一致性的前提下,请提供三种不同成本预算的优化方案”

2.2 话术 – 「见人说人话,见鬼说鬼话」

  • 对老板:「投入 1 个月开发时间,能防止明年 618 大促期间服务器崩溃的风险」,关注成本和产出
  • 对运营:「这个接口延迟降低1秒,首页UV转化率能提升0.7%(附 A/B 测试数据)」,关注指标
  • 对客服:「新系统上线后,用户咨询’物流进度’的话术可以减少 3 次点击步骤」,关注对于其工作的影响

2.3 软技能的红利公式

AI 时代个人价值 = (技术硬实力 × 软技能系数)^ AI 工具适配度  

系数破局点:

  • 会用AI写代码 → 硬实力基准线(人人可达)
  • 能判断该让 AI 写什么代码 → 软技能决胜区(稀缺资源)

那些软技能出色的研发同学,能够借助 AI 实现飞跃式成长,成为团队中的关键角色。

3. 打造你的「AI 时代工具箱」

软技能的提升不是一朝一夕的事,但可以通过系统化的方法论,逐步打造适应 AI 时代的「工具箱」。

3.1 练习「问题之上」的思维:从执行者到问题定义者

AI 工具可以帮助你高效地执行任务,但它无法告诉你「最重要的问题是什么」。在 AI 时代(也不仅仅是 AI 时代),研发需要从全局视角思考问题的本质:为什么做,而不仅仅是怎么做。

3.1.1 如何练习「问题之上」的思维?

每天主动问自己三个「为什么」,从执行层面上升到战略层面:

  1. 为什么这个功能重要?:真实案例:某研发团队接到任务,优化一个页面加载速度。当他们问「为什么优化加载速度重要?」时,发现问题的本质并不在于技术性能,而是用户期望在关键时刻快速获取信息。最终,他们通过简化页面结构和聚焦核心功能,比单纯优化代码更高效地解决了问题。

  2. 为什么用户需要这个解决方案?:从用户视角出发,挖掘需求背后的真实动机。例如,一款 AI 推荐系统的研发团队意识到,用户并不需要复杂的算法结果,而是想快速找到符合场景的解决方案。于是,他们优化了推荐理由的呈现方式,让用户更容易理解和采纳推荐结果。

  3. 如果资源有限,如何找到最优解?:设想一个极限场景:如果只能用 50% 的时间或资源完成任务,你会如何取舍?这种思考方式能帮助你聚焦核心问题,避免陷入无意义的细节优化中。

3.1.2 成为「破界思考者」的 4 层跃迁法

人类擅长于发现隐藏在表象下的真问题。4 层跃迁法帮助突破思维惯性:

▌认知框架

  • 第1层:需求表象:「业务方要求 3 天上线一个推荐算法」
  • 第2层:利益相关者分析:使用 RACI 矩阵梳理:谁决策/执行/被影响
  • 第3层:系统动力学推演:用因果回路图分析技术方案对用户体验/后端负载/商业指标的连锁影响
  • 第4层:第一性原理拆解:追问:用户点击转化率低的根本原因是算法不准?还是商品信息呈现方式问题?

▌实战工具包

  • 丰田「5Why分析法」进阶版

    现象:用户投诉支付失败率上升  
    Why 1 ▶ 接口超时?  
    Why 2 ▶ 第三方支付网关响应慢?  
    Why 3 ▶ 未适配银行新加密协议?  
    Why 4 ▶ 运维监控策略未覆盖合作方变更?  
    Why 5 ▶ 跨部门信息同步机制缺失?  
    
  • MIT系统思考工具箱

记住:AI 再强大,也需要你来定义问题。跳脱「怎么做」的思维框架,才能成为团队中的问题定义者。

3.2 刻意提升「非技术表达」:让技术为业务赋能

技术再高深,如果让人听不懂,价值就会大打折扣。AI 时代的研发者不仅需要写得出代码,更需要讲得清技术。能用简单、直观的方式表达技术方案,既能提高跨部门协作效率,又能让你的工作成果更具说服力。

3.2.1 如何刻意练习「非技术表达」?

  1. 用一张图解释技术架构:将复杂的技术架构简化成流程图、思维导图或者用户体验图。例如,一个后端服务的高可用方案,可以用一张图展示数据流动、容错机制以及业务价值,而不是写一长段技术描述。

  2. 用「用户视角」描述技术方案的价值:比如,你正在开发一个自动化测试工具,与其说「这个工具可以减少测试时间」,不如说「这个工具可以帮助团队提前发现潜在的产品缺陷,从而减少 30% 的用户投诉」。这样的表达更容易被非技术团队接受。

  3. 用故事化的方式呈现你的方案:例如,在解释一个推荐算法时,可以说:「想象一下用户点开首页,看到的是他最喜欢的内容,这背后是我们的 AI 模型在实时分析用户行为。」这种讲故事的方式更具感染力。

3.2.2 实践工具

  • ▌FAB 法则(Feature-Advantage-Benefit)
    表达技术方案时,从功能(Feature)入手,解释优势(Advantage),最后明确带来的好处(Benefit)。

    • 功能:我们的推荐算法会实时预测用户偏好。
    • 优势:它能够在用户访问的第一时间推荐最相关的内容。
    • 好处:提升用户粘性和点击率,从而增加转化率。
    • 例如:
  • ▌SCQA模型(情境-冲突-问题-答案)

    [情境] 当前订单查询 API 响应时间突破 2s  
    [冲突] 用户体验下滑 vs 硬件扩容成本激增  
    [问题] 如何在零成本下优化性能?  
    [答案] 通过 AI 预测缓存热点数据(命中率提升至 92% )  
    
  • 金字塔原理实战:技术方案文档采用「结论先行+ MECE 分类」结构

记住:技术的价值必须通过清晰的表达被团队和业务部门感知,才能真正落地并创造商业价值。

3. 搭建「AI 质检工作流」:让 AI 为你所用,而不是盲目信任

AI 工具再强大,也只是工具,其输出的内容仍然可能存在问题。研发者需要对 AI 的输出保持质疑态度,并建立一套完善的质检流程,确保工具真正符合需求。

▌四阶验证框架

阶段
检查重点
工具/方法
输入层
需求理解偏差
ChatGPT 反向提问验证法
设计层
架构合理性
架构决策记录(ADR)模板
实现层
安全隐患/技术债
SonarQube+AI 代码审计
价值层
商业目标对齐度
OKR-KPI 映射矩阵

当AI工具成为标配,建立质量管控机制比盲目追求效率更重要

4. 用 AI 「解未来」

  • 精准定义问题,让 AI 为你服务,而不是反过来被工具左右。
  • 跨领域协作,用技术思维解决业务问题,成为团队的桥梁。
  • 对 AI 保持质疑,避免高效犯错,用批判性思维守住技术底线。

AI 不会淘汰研发,只会淘汰不会用 AI 的研发。当机器开始思考时,人类的智慧应该闪耀在机器停止思考的地方。

此刻的你,不妨用 0.1 秒思考:是继续做工具的操控者,还是成为驾驭 AI 的「指挥官」?这场进化游戏没有旁观席,每个技术人都已身在局中。

未来的研发工作,不再是机械地写代码,而是以技术为工具,解决问题、创造价值、推动变革

从今天开始,思考:

  • 我的工作是否创造了价值?
  • 我的技能是否放大了 AI 的潜能?
  • 我的软技能是否已跟上时代的节奏?

AI 已来,你准备好了吗? 


「你认为 AI 时代最重要的软技能是什么?欢迎评论留言讨论!」

以上。

AI 编程真的会让程序员失业!

2025 年 1 月 20 日上午 10:24 ,这个包含了 1024 的时间点,字节发布了其 AI 编程 IDE: Trae www.trae.ai/

ai_1.png

对标 Cursor,Windsurf 的国内出海的一个 IDE,当前可使用 Claude-3.5-Sonnet 和 GPT-4o 大语言模型

深入使用,花了三个小时,不写一行代码,实现了一个前端后端分离架构,包含登录/退出,数据库查询,跨域,以及首页功能的小管理后台,包括前端和后端的代码。前端所使用技术栈为 Vue,后端使用了 golang + beego。

这 3 个小时有一个耗时点是想让 AI 来解决跨域的问题,我们知道跨域主要是 Access-Control-Allow-Origin 等头信息的处理,把前后端的代码上下文都给了,反复试 OPTIONS 请求跨域总是不成功,后来发现是后台接口实现所修改的跨域文件没有加载导致的。

除了通用功能,实际业务开发中,花了 30 分钟实现了 Java 的流式输出,其场景是要实现 DeepSeek 的模型调用,以实现打字机的输出效果。 ai_2.png

这里 AI 给的 golang 的实现,但是当前我需要的是 Java 的,这里的问题是没有把需求讲清楚。同时也表示在开始对话时,需要把一些背景信息讲清楚能提高整体的效率。

ai_3.png

ai_5.png

经过了大概 10 轮对话,他大概就了解我真正想要的是什么了,再经过 6 轮对话补全,把过程中有问题的地方和相关代码圈出来给到 AI,很快就有结果,并解决了问题。

ai_6.png

1. 使用过程中的感受

  1. 表述清楚需求很重要,在最开始的时候一些背景重要的背景信息可以提前给出,如技术栈,表结构、想做的事情等等;
  2. 给到更多的上下文,更容易得到正确的答案,在 Trea 中使用 # 号引入,当前支持代码、文件、目录及工作区间;
  3. 从 AI 中来,到 AI 中去,可以跳出 AI 来解决问题,当 AI 限入解决问题的死循环,可以找 google 要一些答案喂给 AI,后续应该会自动支持这个功能;
  4. 出错的地方,选中后,直接让 AI 解决,甚至不需要多说一句话,当然,你也可以多说几句,更清晰的表述你想要的东西;
  5. 多模态的能力,在界面有问题的地方,截图说明给到 AI 就能解决;
  6. 先做框架,再逐个功能实现,当前阶段,AI 解决小范围的问题会更合适一些。

到这里,对于这种通用类的功能,AI 已经能发挥出很大的能力了,再进化一段时间,程序员的大部分编码工作真的就会被 AI 取代了。那是不是我们就失业了呢?从纯粹写代码的角度来说,是的,但是从整个项目的角度不一定。

2. 程序员的当前职责

和康总有聊到这块,当前我们程序员基本在解决的问题包括决策、连接和编码三部分。

  • 决策:技术选型、架构设计等高层次决策,AI 尚无法完全替代。
  • 连接:跨部门需求分析、团队沟通与资源协调。
  • 编码:过去程序员的核心工作,但 AI 的介入正在加速其主要功能的边缘化。

2.1 决策

项目开发的过程实际上是一个个的决策过程组成的,决策是咱们的核心职责之一,是一个项目从业务需求到技术实现的过程中,如何选择解决方案的过程。

我们需要在不确定性和多种选择中,基于经验、知识和实际需求,做出技术上的关键决定。这些决策往往会对团队的效率、产品的质量和未来的技术发展方向产生深远影响。

决策指的它涉及从业务层面到技术层面的全局性规划,包括但不限于:

  • 需求分析
    • 理解并提炼业务需求,制定核心目标和功能优先级。
    • 与产品经理、业务方的沟通,明确业务目标和用户需求。
  • 技术选型
    • 决定使用何种技术栈(前端框架、后端框架、数据库、云服务等)。
    • 评估不同技术的可行性、扩展性和成本。
  • 架构设计
    • 系统架构的顶层设计,比如单体架构 vs 微服务架构。
    • 数据库选择(SQL vs NoSQL)、缓存策略、性能优化方案。
  • 风险评估与管理
    • 评估技术方案的风险(如性能瓶颈、技术债务、团队技术栈能力)。
    • 制定备选方案和应急措施。

AI 替代能力:

  • 当前能力
    • AI 已能提供强大的技术选型建议(如根据场景推荐框架、库、工具)。
    • 在简单的架构设计中,AI 已能生成初步方案(如微服务与单体架构优劣分析)。
  • 未来潜力
    • AI 可能在复杂的技术决策中辅助更精准的数据分析和方案评估。
    • 但最终决策依赖对业务需求的深刻理解,这仍需要人类的经验和判断。

程序员核心竞争力:

  • 理解业务需求和行业背景,能够将技术与业务深度结合。
  • 解决复杂的非结构化问题,比如协调跨团队需求冲突,平衡业务优先级。
  • 创新能力:AI 只能在已有知识中提供建议,真正的创新需要人类。

2.2 连接

连接是将技术方案具体化并协调各方资源,使其从理论走向实践的过程。重点包括:

  • 需求转化
    • 将业务需求拆解为可执行的技术任务。
    • 明确模块划分、接口定义以及交互方式。
  • 团队协作
    • 前后端、测试、运维、产品经理之间的沟通与协作。
    • 协调跨部门资源,解决技术与运营、市场等职能间的矛盾。
  • 接口与模块设计
    • 定义 API 接口规范(RESTful、GraphQL)。
    • 确保接口的安全性、性能和兼容性。
  • 测试与迭代
    • 制定测试方案,组织单元测试、集成测试。
    • 根据测试反馈快速调整,推动迭代优化。

AI 替代能力:

  • 当前能力
    • AI 已能快速生成接口文档、代码示例、测试用例。
    • 在协作方面,AI 可以辅助生成任务拆解、需求文档、项目计划等。
  • 未来潜力
    • AI 可以成为跨部门的沟通桥梁,如生成更加精确的技术-业务对接文档。
    • 但复杂、动态的沟通和协调仍是 AI 难以替代的领域。

程序员核心竞争力:

  • 优秀的沟通能力和团队协作能力,能在矛盾或模糊的需求中推动项目前进。
  • 对复杂系统的整体把控力,确保各模块之间的高效协作。
  • 快速适应变化的能力,能够在项目中临时调整资源和策略。

2.3 编码

编码是程序员的核心工作之一,涉及将设计方案转化为实际运行代码的过程。它包括:

  • 代码实现
    • 基于需求和设计文档,开发具体功能模块。
    • 包括前端开发(UI、交互逻辑)和后端开发(业务逻辑、数据库操作)。
  • 调试与优化
    • 修复 BUG,优化代码性能。
    • 解决复杂的技术难点(如跨域问题、性能瓶颈、并发冲突)。
  • 代码质量保障
    • 编写单元测试、集成测试,确保代码质量。
    • 遵循代码规范,进行代码审查。
  • 持续集成与发布
    • 使用 CI/CD 工具进行自动化构建和部署。
    • 实现代码版本管理和持续优化。

AI 替代能力:

  • 当前能力
    • AI 已能生成高质量的代码片段、调试建议,甚至完整的模块代码。
    • 对于常见的编码任务(如脚本处理类,CRUD 功能),AI 的效率和准确性已超过人类。
  • 未来潜力
    • AI 将进一步替代大部分重复性、模板化的编码工作。
    • 但对于复杂场景下的创新性编码,AI 的能力仍有限。

程序员核心竞争力:

  • 对技术深度的理解,能够在 AI 提供的代码基础上进行优化和扩展。
  • 解决复杂问题的能力,比如在非标准化场景下实现创新功能。
  • 对代码质量的把控能力,确保生成代码的安全性、性能和可维护性。

3. AI 替代的趋势与程序员未来的价值

3.1 当前 AI 会逐步替代哪些部分?

  1. 重复性、模板化的工作
    • 例如脚本类、通用类、CRUD 重复类的功能。
    • 常见的 BUG 修复、代码优化建议。
  2. 常规化的架构设计和技术选型
    • AI 将能处理大部分标准化场景下的技术决策。
    • 在数据驱动的决策场景中,AI 的效率更高。
  3. 文档、接口、测试的自动化
    • 自动生成 API 文档、测试用例,将成为默认功能。

3.2 程序员的核心竞争力是什么?

  1. 业务理解与技术结合能力
    • AI 不理解业务逻辑背后的真实需求,程序员能够通过与产品、业务沟通,设计出更贴合实际的解决方案。
  2. 复杂场景的解决能力
    • 比如跨团队协作、大规模分布式系统设计、非标准化需求的实现。
  3. 创新与创意能力
    • AI 是基于已有数据训练的,无法真正创新。程序员在新领域和新需求中的创意能力不可替代。
  4. 人际沟通与团队协作能力
    • 项目中的决策、问题协调、资源整合都需要人类来推动。

3.3 程序员未来应该做什么?

  1. 提升抽象能力和建模能力
    • 从写代码转向设计方案,专注于高层次的架构和技术规划。
  2. 拥抱 AI 工具
    • 熟练使用 AI 编程工具(如 Trea、Cursor)提升效率,将 AI 当作“助手”。
  3. 深耕行业知识
    • 了解特定行业的业务逻辑,成为领域专家。
  4. 培养软技能
    • 强化沟通能力、团队协作能力和项目管理能力。

画了一个思维导图,大概是这样:

ai_sj.png

 

Cursor AI 编程让我的编码效率提升了 10 倍

从 2022 年 6 月底正式上线的 GitHub Copilot 开始,AI 编程逐步开始进入工作的环境中,开始成为一个真正的 Copilot。据当时微软的评测报告以及当时公司内部使用的问卷反馈调查显示提升效率大概在 10% ~ 30%。

这一数据在当时已经令人惊叹,但随着大语言模型的飞速发展,以及 Cursor、Windsurf 等新一代 AI 编程工具以更直接的 IDE 方式的加入,效率提升的天花板被彻底打破。

从个人体感来说,部分场景有超过 10 倍的提升,特别是通用类功能实现,如爬虫、CRUD 功能、脚本类处理等。但并不等于以前一个项目要 10 个人,现在只需要 1 个人了,毕竟编码在整个项目过程中只占用的时间资源的一部分。

而且,这里的提升并不是说给 AI 说一句话:「给我完成 XXX 功能」,就能直接提效 10 倍 ,当前阶段,我们还需要有一些使用技巧才能较好的使用 AI 编程,让 AI 编程成为一个实实在在的助手。以下为过程中的一些注意事项和一些可能遇到的问题。

1. 使用 AI 编程的注意事项

1.1 不要求一次性完成所有的工作

AI 编程工具暂时并不擅长处理复杂且模糊的任务,而是更适合解决清晰、具体的小问题。因此,任务分解是高效使用 AI 编程的第一步。

如何实现?

  • 需求分解:将大任务拆解为小模块,可以人工分解,也可以让 AI 协助分解。例如:

    • 开发一个后端服务时,可以分解为:数据库表设计、路由框架搭建、业务逻辑实现、测试用例编写。
  • 框架优先:先让 AI 生成代码框架,例如接口的骨架代码、类和方法的定义,然后再逐步实现具体功能。

以一个简单的任务管理系统为例,你直接告诉 Cursor 「帮我实现任务管理功能」,他会提示你给出更多的输入,比如所要使用的技术栈等等,如果我们输入:请用 python 语言作为后端,vue 作为前端帮我实现任务管理功能。他会给出完整的看起来可以使用的架子,实际不太能用。

如果是在一个已有项目的基础上增加模块,以 CRUD 管理任务来说,较好的做法是:

  1. 分解需求

    • 第一步:设计任务表(表结构设计),也是明确核心需求的过程;
    • 第二步:实现核心的接口和界面;
    • 第三步:添加权限管理,一般是有权限体系,可以给参考或者表结构之类的实现;
  2. 逐步实现

    • 先让 AI 生成数据库表的定义,明确需求及约束;
    • 再生成 API 的路由框架。
    • 最后逐一实现各个功能模块。
    • 在各功能模块上再扩展其它的需求,如在任务添加的时候要调起弹性接口去完成任务等。

1.2 明确和细化需求

明确和细化需求和第一点有一些不同,这里所要表达的是我们在需求描述时要尽可能的明确和细致,以及需要有我们的转化和理解。

当前阶段,我们用 AI 编程并不是把产品需求扔给 AI,而是我们思考过整个实现的过程,有自己的认知后让 AI 来做会更好,当然,这个思考的过程也可以让 AI 来辅助。

  • 明确需求的层级

    假设你需要实现一个用户登录功能,可以先从高层次的需求入手「实现用户登录功能」,然后逐步细化为:

    • 数据库中需要存储哪些信息?
    • 前端需要提供哪些输入?有没有什么安全输入策略?
    • 后端服务的接口设计是什么样的?格式是怎样的?返回码规范是怎样的?
    • 需要哪些验证逻辑?使用 JWT 还是 Auth2.0?有哪些安全策略?
  • 细化到函数级别

    在某些情况下,有必要直接将需求分解到函数的输入输出、核心逻辑或算法。比如:

    • 函数应该接受哪些参数?
    • 输出的结果应该是什么样的?是什么类型的数据结构?
    • 核心逻辑是否需要特殊的算法优化?

以上这个细化的过程也是个 AI 交互的过程,从大到小,从整体到部分,逐步完成整个需求

在使用 AI 编程的过程中,确定需求并细化需求是最难,也是整个过程中最复杂的环节,因为它是对现实世界的建模。

把产品需求没有歧义的描述出来,这个过程远没有很多人想象中那么简单。期待 AI 进一步进化后能优化这部分理解的工作。

1.3 善用 AI 的上下文记忆

AI 编程的生成效果在很大程度上依赖于上下文信息

Cursor 支持上下文记忆功能,可以根据当前项目的代码结构或对话历史生成更精准的结果。并且对于已有代码的项目,提供示例代码给 Cursor 参考,可以帮助它更好地理解项目的整体风格、编码规范以及约定。

  • 参考已有代码

    比如,我们可以将公司内部的编码规约或项目约定通过已有代码的形式提供给 AI,这样生成的代码更符合项目需求,减少后续调整的工作量

  • 让 AI 理解当前代码环境

    在和 Cursor 对话时,可以特别的指出关键代码片段(如数据模型、核心函数),这种方式是为了规避 LLM 的上下文记忆的限制问题,突出当前要解决的问题和场景。

  • 补充上下文

    如果项目中有复杂的业务逻辑或特定的技术约定,可以通过注释、文档或已有代码的形式向 AI 提供相关背景信息。这样,AI 生成的代码不仅能够「跑通」,还更贴近实际需求。如使用 Cursor 的 @ 符号,除了本地的代码、文档、还可以有多模态的图片、外部链接的文档,Web 网页等等。

2. AI 编程使用中的问题及解决方案

在使用 AI 编程工具(如 Cursor、Windsurf 等)时,尽管其效率提升显著,但也有一些问题亟待解决。

2.1 额度不够了

以 Cursor 为例,即使在不大量使用的情况下,Pro 版本(如 GPT-4、GPT-4o、Claude 3.5 Sonnet 的高速请求)两周内就可能用完额度。高级模型的调用成本较高,尤其是当需要生成大量代码或反复调试时,消耗会非常快。

解决方案:

  1. 分工明确,优化工具使用场景

    • 代码相关任务交给 Cursor:专注于代码生成、函数实现等任务,减少对 Cursor 的非核心调用。
    • 知识性问题交给 ChatGPT或其它大语言模型:对于纯知识性或逻辑性的问题,使用 ChatGPT 或其他不限量的模型(如 GPT-3.5 免费版本)来查询。
  2. 分层实现代码

    • 先写框架:在开发项目时,先用 Cursor 生成代码框架,明确主流程。
    • 逐步细化:将需求明确的函数(尤其是复杂的小块代码)交由 Cursor 实现,而非一次性生成庞大的代码段。
  3. 结合其他无限制的大模型

    • 对于通用型函数(如工具类代码、简单的逻辑实现),可以利用免费的语言模型完成。
    • 配合使用多个编辑器(如 Windsurf 、Cursor、豆包),减少单一工具的使用频率。
  4. 节约上下文消耗

    • 避免在上下文中反复输入无关信息,尽量精简对话内容。
    • 善用工具内的上下文管理功能,如 Cursor 提供的 Add context@ 引用功能,将关键信息外部化,减少重复输入。

当然,对于不差钱的小主来说,可以忽略此问题。

2.2 上下文限制:会「失忆」

当前的 LLM 上下文窗口有限,当输入信息超出限制时,模型可能会「遗忘」之前的内容。这种「失忆」表现尤其明显,例如在多次会话后,最前面的一些关键信息可能会被遗忘,导致生成的代码出现不一致的问题。

解决方案

  1. 简要总结关键信息

    • 当模型开始「失忆」时,可以总结项目的关键信息并重新输入。例如, 核心配置或表结构可以作为关键信息,在对话开始时就输入给 LLM,确保其随时可用。
  2. 外部化核心信息

    • 将一些不变的核心信息(如数据库表结构、配置文件、接口定义等)存储到单独的文件中。
    • 在对话中通过 @Add context,将这些文件动态添加到上下文中,避免重复输入。
  3. 引用外部文档

    • 将外部帮助文档、链接或者参考资源作为上下文的一部分添加到对话中。例如,直接粘贴代码库的 README 文件、API 文档链接等,可以帮助模型更好地理解当前任务。
    • Cursor 自身支持这些外部的引用,具体方法参见 Cursor 的帮助文档,探索上下文扩展功能。
  4. 优化上下文使用策略

    • 尽量减少对话中的无关内容(如闲聊或冗长描述)。
    • 定期总结对话内容并清理上下文,确保关键信息占用优先位置。

2.3 修改代码混乱:会改乱代码

AI 工具在生成代码时,可能覆盖或修改原有代码,导致逻辑混乱,甚至出现功能性错误,一不小心原来能跑通的功能就不通了。这种情况常发生在对已有代码进行修改时,尤其是在多次修改的情况下。

解决方案

  1. 结合版本控制工具

    • 在完成每一阶段的明确功能后,及时使用 Git 提交代码,确保已有的工作成果被保存。
    • 在尝试新的修改时,可以创建分支或临时提交,确保不影响主分支的代码完整性。
  2. 分步引导 AI

    • 避免一次性让 AI 修改大量代码,而是按功能模块逐步进行修改。例如,先让 AI 修改某个函数,再验证其效果,而不是直接让它大规模重构代码。
  3. 生成新代码替代旧代码

    • 在涉及复杂逻辑的修改时,建议让 AI 生成新的代码片段,而不是直接修改现有代码。我们可以手动选择将新代码合并到项目中,避免出现覆盖错误。
  4. 代码审查

    • 对 AI 生成或修改的代码进行人工审阅,尤其是涉及关键逻辑的部分,确保生成代码符合预期。

2.4 无法解决复杂问题:可能进入死循环

在调试复杂问题或某个难点时,AI 工具可能陷入死循环,反复尝试生成代码但无法有效解决问题。例如,AI 对某个 bug 的修复建议多次尝试后仍然无效,甚至可能导致代码更加混乱。

解决方案

  1. 重新整理问题

    • 如果问题复杂而模糊,先关闭当前对话,重新开启一个新的会话。
    • 将问题简化为多个子问题,并逐步整理关键信息后输入给 AI。例如,将错误日志、上下文代码片段和预期行为整理成清晰的描述。
  2. 结合搜索引擎

    • 对难以解决的问题,可以将错误信息、bug 的关键描述扔给搜索引擎,结合开发者社区(如 Stack Overflow)寻找答案。
    • 搜索的过程中可以收集更具体的上下文,再反馈给 AI,增加其解决问题的可能性。
  3. 寻求多工具协作

    • 如果单个 AI 工具陷入死循环,可以尝试切换到其他工具或模型。例如,Cursor 无法解决的问题,可以切换到 ChatGPT 或 Claude 进行尝试。
    • 结合传统的调试手段(如 IDE 的调试功能、日志分析工具等),帮助定位问题。
  4. 分阶段测试

    • 将复杂问题拆解为多个小问题,逐步测试每一部分的结果。例如,如果某个模块的逻辑无法正常运行,可以先测试其输入输出,再逐步调试内部逻辑。

3. 小结

用 AI 编程,也就是和 AI 协作,本质上是一种双向的沟通过程。

我们需要像与团队成员协作一样,清晰表达需求、提供必要的背景信息,并通过持续的反馈和迭代优化,逐步引导 AI 生成符合预期的结果。只有做到有效沟通,AI 才能真正成为开发者的高效助手,而不是一个需要频繁纠错的工具。

以上。