开这个号，聊聊AI与软件工程那些尚未有答案的事

开这个号聊聊AI与软件工程那些尚未有答案的事视频开这个号聊聊AI与软件工程那些尚未有答案的事写在前面过去三年我深度参与了 AI 辅助软件工程的实践从最早的提示词摸索到后来在真实项目中落地 Agent 工作流过程中踩了不少坑也积累了一些观察和判断。身边越来越多朋友问我AI 到底会怎么改变软件工程BA、PM、SA 这些角色会不会被取代我们应该学什么、做什么这些问题我无法给出标准答案——因为整个行业也还没有。但我认为持续地实践、持续地观察他人的实践、持续地澄清问题的演进方向本身就是最有价值的回应。这就是开这个号的初衷。接下来我会从几个方向持续展开先说说我最关注的切入点。一、AI Coding 的发展从三个关键词看趋势AI Coding 领域的变化速度可能是整个软件工程行业几十年未见的。我想从两个维度来梳理方法论层面和模型层面。方法论层面Prompt → Context → Harness如果你回顾 AI Coding 的演进会发现人们关注的重心在快速迁移第一阶段提示词工程Prompt Engineering最初大家关注的是如何写一个好的 prompt。指令要清晰、格式要对、要给示例——像一个手艺活。那时候流传一句话“AI 的上限取决于你的 prompt 水平”。这个阶段的核心命题是如何让 AI 理解我想要的。第二阶段上下文工程Context Engineering很快人们发现prompt 写得再好如果 AI 缺少足够的上下文输出质量也上不去。于是开始关注 RAG、关注知识库、关注如何把项目代码库、业务文档、历史记录组织成有效的上下文。Cursor 的 file、Claude Code 的项目感知能力本质上都是在解决同一个问题如何让 AI 知道我有什么。这个阶段的核心命题从说清楚升级为喂对料。第三阶段驾驭工程Harness Engineering而现在我观察到第三个趋势正在浮现。随着 Agent 的自主性越来越强AI 不再是问一句答一句的工具而是可以独立执行多步任务的工作伙伴。这时候核心问题变成了如何让 AI 在真实生产环境中可靠地工作。这不仅仅是模型能力的问题而是一个系统工程问题——涉及 Agent 的编排、工具链的集成、安全边界的设定、输出质量的校验、异常的处理等等。我把它叫做驾驭工程Harness Engineering。从 Prompt 到 Context 再到 Harness这三个阶段不是替代关系而是层层叠加。今天做 AI Coding三个层面的能力都要考虑。模型层面多项关键参数在快速跃迁与此同时底层的模型能力也在经历剧烈的变化。这些变化直接影响着上层工程实践的方式。参数规模的变化从 GPT-3 的 175B到 GPT-4 的传闻 1.8T再到现在的 MoE 架构、小型专业化模型并存——参数不再是唯一指标合适的大小比更大的模型更关键。模型架构的变化Transformer 一统天下的局面正在松动。RWKV、Mamba 等状态空间模型在探索更高效的架构DeepSeek 的 MLAMulti-head Latent Attention在推理效率上的突破——架构层面的创新可能会重新定义什么是好的代码生成模型。上下文长度的变化从最早的 4K 到 32K、128K、1M再到现在的 10M token 级上下文。这件事对软件工程的影响可能被严重低估了。当 AI 可以看完整个代码仓库、整个项目文档、甚至整个公司的技术规范时很多我们习以为常的工作方式都会变。单一模态到多模态不仅仅是文本流程图、架构图、UI 设计稿、甚至是手绘的白板草图都正在成为 AI 可以理解和生成的输入输出形态。这对 BA画流程图、SA画架构图的工作方式影响会是结构性的。二、AI 没有消减知识资产的价值反而在放大这一点可能是最容易被误解的。大模型确实摄取了海量的公共知识和经验——几乎所有公开的代码、文档、讨论都被训练进去了。有人因此认为个人的经验和知识不再值钱了。我的观察恰恰相反。从几个现象说起第一越来越多企业在返聘资深员工。为什么因为大模型可以提供通用的、平均水平的答案但无法替代对这个组织、这个业务、这个系统的深入理解——而这些恰恰是资深员工多年积累的资产。第二资浅员工的招聘在缩减。不是因为不需要人而是因为一个资深 AI的组合正在替代一个资深 两个资浅的配置。AI 让经验丰富的人效率倍增但并不能把没有经验的人变成有经验的人。第三个人和组织在知识和经验上的价值变现系数其实在提高。什么意思同样一份领域知识在没有 AI 的时代你可能只能通过做项目来变现效率是线性的。但在 AI 时代你可以将这份知识封装为技能、知识库、工作流模板——让 AI 替你规模化输出。你的经验被复用了无数次而不再是一次性的。换句话说AI 不是来取代你的经验的而是来给你经验的变现加杠杆的。三、问题一软件工程的流程范式将如何演进我越来越频繁地想一个问题在 AI 的冲击下软件工程的流程范式会发生多大的变化回顾历史从瀑布模型到敏捷模型那是一次跨越式的范式转换改变了整个行业的工作方式。而我认为AI 带来的范式转换不会亚于那次变革。为什么瀑布到敏捷解决的是需求变化太快没法一次性做完的问题。那么 AI 解决的是人做不了那么多重复性脑力劳动的问题——但它带来的连锁反应远不止于提效。几个我还没有答案、但持续在想的问题当 AI 可以一人完成从前需要多个角色协作的工作时项目团队的结构会发生什么变化当需求分析、方案设计、代码实现之间的边界被 AI 模糊时流程应该如何重新定义当 AI Agent 可以自主执行任务、但需要人类做关键决策时评审和反馈机制应该怎么设计需求→设计→开发→测试→部署这条流水线会不会被完全不同的范式替代目前我看到的是行业还没有出现被广泛接受的 AI 时代软件工程范式。有些团队在用AI 辅助敏捷的方式有些在尝试Agent 驱动的流水线还有些在探索人机协作的新角色划分——但都还在实验阶段。这正是值得持续关注和实践的方向。四、问题二LLM Agent 的结构化组件正在成为组织资产另一个值得关注的方向是 LLM 驱动的 Agent 正在呈现出越来越清晰的结构化特征。我说的不是某一个 Agent 框架的实现而是整个领域在自然演化出的共性组件技能SkillsAgent 能做的事被逐步封装为标准化的技能单元。比如需求分析技能“代码审查技能”“架构评估技能”。这些技能正在从代码库中独立出来成为可复用、可组合、可共享的模块。知识KnowledgeRAG 只是开始。更精细的知识组织形式正在出现——不只是把文档向量化存起来还包括知识图谱、决策规则、领域专有逻辑的显式表达。工具ToolsMCP 协议的出现是一个重要信号。工具不再是写死在 Agent 代码里的函数调用而是变为可通过标准化协议发现和调用的服务。这意味着工具层正在和 Agent 逻辑层解耦各自独立演进。记忆Memory短期记忆、长期记忆、经验回放——这些概念正在从 AI 研究的论文中走向工程实现。Agent 开始能记住上次这么做遇到了什么问题而不是每次都从零开始。更重要的是这些组件之间的关系正在逐步清晰。一个 Agent 如何利用知识库中的业务规则调用 Skill 完成特定任务通过 Tool 访问外部系统并利用 Memory 持续改进自己的表现——这个协作模式正在从手动的拼凑走向架构层面的规划设计。对组织而言这意味着什么这些组件未来会是组织的关键资产。就像今天企业的代码库、数据库、架构文档一样明天的核心竞争力可能来自于你的 Skill 库有多完善、你的知识库有多精准、你的工具链有多集成、你的 Agent 记忆有多丰富。而如何维护和管理这些资产以及如何让这些资产真正有效地驾驭真实生产——目前还有很大的想象空间。五、这个号打算做什么回到开头。我开这个号的目的不是给出标准答案——因为我也没有。而是第一持续实践。我会在真实项目中持续用 AI 做软件工程相关的事然后把过程中的收获、踩坑、反思写出来。不是抽象的理论讨论而是我试过了效果如何以及为什么。第二持续观察。关注行业内其他人的实践——海外的、国内的、不同规模团队的、不同角色的。AI 软件工程这个领域现在最好的学习材料就是别人的实战记录。第三持续澄清。上面提到的两个问题——软件工程范式会怎么变、Agent 组件资产如何管理——都会随着行业实践而逐步清晰。我会持续跟踪这些问题的演进在每一个阶段把目前我们知道什么梳理清楚。关于内容方向我主要会涉及这些话题AI Coding 的工程实践与思路演变BA / PM / SA 等角色的 AI 赋能LLM Agent 的组件化与资产化管理MCP 协议与工具生态软件工程流程的 AI 时代范式关于更新方式这个号不会追求每日更新但会保持每周至少一篇原创输出以及不定期的行业动态转述和解读。质量优先长期主义。如果你对这些话题也有兴趣欢迎关注。也欢迎在评论区或后台分享你的实践和观点——这个领域现在最缺的不是信息而是对话。