AI 正在重构软件工程：认知、创造力与执行力如何成为真正的优势

date

Oct 30, 2026

status

Published

slug

ai-software-engineering-cognition-and-action

一、先把“软件工程被淘汰”拆成三个问题

第一，某些任务会不会被自动化？会，而且已经值得在具体工作中测试。

第二，岗位的工作内容、人员配置和招聘要求会不会改变？很可能，但变化的速度与幅度取决于企业、场景和系统复杂度。

第三，软件工程作为一整套需求分析、设计、实现、验证、运行和维护活动，是否已经不再需要？现有证据不足以支持这个结论。

一个可运行的页面，与一个能长期承载真实业务的系统，之间还有权限、数据一致性、异常恢复、安全、成本和持续演进。

AI 可以参与这些环节，甚至承担越来越多工作。但“谁确定目标、谁验证结果、谁承担上线后的责任”，仍然必须被回答。

因此，更值得警惕的，是某些技能的稀缺性和议价能力下降。它可能带来真实的岗位压力，但不能据此把每个人的处境简单归结为“认知不够”或“不够努力”。

二、把几类观点放在一起看

观点一：AI 确实能够提高一些开发任务的产出。

微软研究院收录的一项研究汇总了三家企业、4,867 名开发者的随机试验，合并估计显示，使用 AI 工具者的任务完成量增加约 26%。这是特定企业与工具条件下的产出结果，不能直接换算成节省多少工时或可以减少多少人员。研究摘要，2025 年 6 月。

观点二：工具变强，并不意味着任何场景都已经测得稳定收益。

METR 的早期实验中，16 名熟悉各自开源项目的开发者处理了 246 项任务，使用当时 AI 工具后反而平均多花了 19% 的时间。但这个结果对应的是早期 2025 年的工具与特定场景。2026 年 2 月，METR 更新称新工具很可能更能提速，同时指出后续实验存在严重选择偏差，尚不能可靠估计收益。两次研究合起来，更适合说明持续测量的重要性。原始论文、2026 年更新。

观点三：组织能力决定生成速度能否变成交付能力。

DORA 2025 的调查发现，AI 采用与交付吞吐、产品表现呈正相关，但与交付稳定性仍呈负相关。这里是调查关联，不是严格的因果证明。它提醒团队同时改善测试、反馈和工程基础，不能只追求代码生成速度。DORA 官方解读。

观点四：减少手工编码，并不免除工程责任。

开发者 Simon Willison 在讨论 vibe coding 时，把不审阅生成代码的探索，与需要理解和负责的 AI 辅助开发区分开来。这是实践者的判断：专业交付仍要处理安全、维护、性能和成本等约束，而不是只看程序能否启动。原创文章，2025 年 3 月。

观点五：任务受到影响，与整个职业消失，是不同问题。

国际劳工组织 2025 年研究认为，生成式 AI 带来的工作转型比岗位整体被取代更可能。它研究的是潜在任务暴露，并不是已经发生的失业，也不保证个别岗位不会减少。ILO 研究简报。

这些材料提示我们，讨论 AI 时至少要区分三种东西：特定任务上的速度、完整交付流程的表现，以及未来劳动市场的变化。

前两者可以通过实验逐步测量；第三者还受到需求增长、组织调整、成本和市场竞争影响。不能拿一个演示或一项局部实验，直接宣布整个行业的最终结局。

三、未来更需要怎样的复合型人才

我认同原始观点中的方向：认知、创造力和执行力，会成为更值得投入的能力。

但“复合型”不能只理解为会很多工具、懂很多名词。更实用的结构是：在一个领域有足够深度，又能把问题判断、AI 使用、结果验证和沟通交付连起来。

1. 读书，积累能独立判断的知识

读书的价值，不在于完成多少本书，也不在于借知识证明自己比别人高级。

它帮助人建立概念、理解因果、认识历史经验，并看到当前问题之外的可能性。专业文档、论文、用户访谈和亲手实践，同样可以成为高质量输入。

如果只让 AI 总结观点，却从不检查原文，也不理解推理过程，我们可能得到更多结论，却失去判断这些结论的能力。

一种可执行的方法是：围绕正在解决的问题阅读，写下自己的判断，再让 AI 寻找反例，最后回到事实和实践验证。

2. 创造力，把真实需求变成值得做的东西

AI 能提供很多候选方案。真正困难的，往往是决定哪些方案值得投入。

一个功能是否必要？用户为什么没有采用现有方案？看起来很先进的产品，是否只是增加了新的操作负担？

创造力可以来自新的组合，也可以来自对一个旧问题更准确的理解。理解用户为什么反复犯错、为什么绕开流程、为什么不愿付费，可能比再增加一个 Agent 更有价值。

3. 执行力，把想法推进到经过检验的结果

执行力不宜用生成了多少代码、同时启动了多少任务衡量。

更有价值的执行，是把目标拆小，明确验收标准，及时测试，在出现问题时修正，并完成交付。

AI 加快实现之后，错误方向也可能被更快放大。一个人需要学会在不同阶段切换角色：提出目标、检查假设、安排执行、验证结果、决定是否继续。

4. 热爱生活，保留问题来源与自己的尺度

生活经验能帮助我们理解真实的人：他们怎样安排时间、表达需求、处理麻烦，以及为什么不愿使用某个产品。

运动、家庭、阅读、旅行或日常观察，都可能给创造提供素材，也能帮助人不被工具迭代完全牵着走。

但“热爱生活”不是职业资格，更不能用来判断一个人是否值得成功。人会经历疲惫、困境和不同的人生阶段。这里想强调的是：尽量保留对现实的观察和好奇，而不是把全部注意力交给排行、热点和比较。

四、学习别人、关注同行、谨慎使用 AI，并不等于落后

原始观点里，对抄袭、攀比和拒绝 AI 的批评，有一个值得保留的核心：长期停留在被动模仿和外部评价里，很难形成自己的方向。

但这几个问题需要拆开。

学习成熟方法，与侵犯他人成果不同。 软件工程本来就依赖复用和合作。遵守许可、理解原理、根据实际问题改进，比为了“原创”重复造轮子更有效。

了解同行，与把自我价值交给比较不同。 外部基准可以帮助校准，但不能替代自己的用户、成本和交付结果。

谨慎使用 AI，与拒绝学习不同。 数据保密、输出可靠性、合规和成本，都是合理约束。更好的姿态是选择安全、可验证的任务试用，而不是盲目接入或一概排斥。

人也不是只能被分成“会用 AI 的赢家”和“不会用 AI 的输家”。工具使用需要学习条件和组织支持，转型压力值得认真对待。

五、个人可以怎样开始：一个四周实验

与其急着给职业下结论，不如选择一个自己熟悉的小问题，做一次完整实验。

以下是一套可调整的起点，不是四周就能完成职业转型的承诺。

第一周：选问题，建立基线。

选一个真实、重复出现、结果可核对的任务。比如整理公开资料、处理测试数据，或给自己的小工具补一项功能。

先记录原来的完成时间、错误类型和返工量。明确什么叫完成，哪些事情不能交给 AI，以及哪些数据不能上传。

第二周：让 AI 参与，但保留检查点。

让 AI 帮助拆解任务、提出方案和生成初稿。对关键结论回查来源，对代码运行测试，对有副作用的操作保留人工确认。

记录工具费用、提示与调试时间、审阅时间。不要只计算它第一次给出答案有多快。

第三周：交给真实使用者检验。

邀请少量合适的使用者试用，观察他们能否独立完成目标。先问遇到了什么障碍，再问是否喜欢。

保留失败样例：理解错需求、遗漏边界、生成无法运行的代码、错误引用资料。它们比一次顺利演示更能指导下一步改进。

第四周：复盘，决定保留什么。

比较总耗时、错误率、返工量和实际使用价值。样本很小时，不急着宣称效率提高了多少倍。

把有效流程整理成检查清单，把稳定的功能沉淀成工具；无效的部分缩小范围或停掉。下一轮再选择更有价值的问题。

这一过程同时训练四件事：识别问题、使用 AI、验证结果、完成交付。

六、团队需要解决的，不只是员工会不会写提示词

如果组织只要求“全面使用 AI”，却不改变验收、权限和协作方式，工具越强，混乱也可能越快。

可以从五个具体动作开始：

按任务复杂度和风险分层，优先选择容易验证、失败代价低的工作。

建立共享的需求说明、测试样例和代码规范，让 AI 与人都有可靠上下文。

保留代码审查、安全检查、发布审批和回滚能力，不能用生成速度替代工程门槛。

评价交付质量、周期和用户结果，避免按代码行数或 AI 使用次数排名。

为新人保留学习路径，让他们解释设计、定位故障、补充测试，而不只是接受生成结果。

团队还应防止知识只沉淀在少数人的聊天记录里。可复用的说明、测试和决策记录，才能让个人经验逐步成为组织能力。

AI 可能降低某些实现成本，同时提高检查、协调和责任划分的重要性。预算与人才培养需要一起调整。

七、认知、执行与生活，应当形成循环

“拼认知”不是收集更多观点，而是让判断更贴近现实。

“拼执行”不是让自己永远忙碌，而是持续完成值得做的事情。

“拼热爱生活”也不是展示一种理想人设，而是尽量保持观察、感受和自主选择的能力。

把它们连起来，才是一条更稳的路径：

从生活和工作发现问题，通过阅读与实践理解问题，用 AI 降低尝试成本，再用真实结果修正判断。

软件工程会怎样变化，还需要持续观察。但没有必要等行业结论落定，才开始调整自己的能力结构。

今天就可以少追一个热点，多理解一个用户；少生成一批无人检查的代码，多完成一个有人真正使用的功能。

当实现越来越容易，重要的是更清楚地知道：为什么做、为谁做、怎样证明做好了。

本文基于所提供观点整理拓展，研究与观点来源核对截至 2026 年 10 月 30 日。对职业与能力变化的判断属于分析，不把局部研究结果视为所有团队或未来工具的共同结论。