01 欢迎来到未来

视频地址

AI总结

模型：ChatGPT-5.6 Sol High

Agent 带来的变化，不只是“写代码更快”，而是让软件工程重新把重点放回“如何保证事情最终被做对”上。 整节内容逻辑链：LLM 提升单点任务能力 → Agent 延长反馈回路、持有状态、操作外部世界 → 一个人开始能够承担过去一个团队的工作 → 但系统工程的复杂度并没有消失 → 因此软件工程反而变得更重要。

软件工程研究的：”怎样让工程不失败“

  • AI可以加速实现，却不会自动暴露未知、分配责任或验证结果
  • 工程的目标是让系统在约束、变化和协作中继续活着

LLM和Agent

LLM：一个概率分布Pr [token|context]

  • 反馈回路越来越长
  • Context可以成为可写的状态

使用Agents

从”回答问题“到”把事情推进“

  • 最小原则：现在开始用、随时询问
  • 想象力限制了Agent能够完成的任务
  • 先用好、再理解原理 —— 颠覆了计算机中”学习曲线太陡“的问题，学习曲线从”记住每一步“变成”判断结果是否正确“

Agent拥有完整的生态系统 -> Browset Use/Computer Use，应当用插件把浏览器管控起来。

  • 让Agent探索页面、理解流程、完成一次任务 -> 让Agent 沉淀成脚本。
  • 标准解法：信息源 -> 信息处理 -> 操作。
  • 工作流自举：观察操作 -> 发现重复模式 -> 生成自动化 -> 回放验证 -> 人确认 -> 收集新异常

未来已来，Agent未稳

OpenClaw/Hermes预见了这样的未来（全自动工作流），但体验还不够好。Agent可以造出任何东西，包括视频、论文、东西（VibeFab）。

  • Q：那么直接让AI造航母？
  • A：事实上产品是系统性的工程，任何一个环节都不能缺失、也不能组织不当。

Prompt的差异

  • 跑出来，不等于做成：可能可以完成任务，但没办法维护（没有好的软件架构）
    • Intent Space / 意图：需求的提出者也不确定100%要什么（”帮我做一个淘宝“？甲方）
    • Spec Space / 发出的指令：从Intent到Spec，已经曲解很多
    • Impl Space：计算机程序只接受100%无歧义的命令
    • （OS：感觉很像传话游戏产生的曲解意思）
  • 模型补gap的方法是猜测，尽量快完成任务。但实际上应当先讨论一下，再完成任务。
    • 一旦在重大决策犯错，就要用巨大的成本来补（eg. Token、消耗的时间）
    • 大模型不会像人一样有重构的意识。
    • 当一个产品开始产生slop之后，投入更多的token只会产生更多的失败（耦合、隐含的知识和验证所需的债务）

软件工程所研究的

怎样把一件大事，在人和工具的共同协作下完成。

  • 失败 = 软件不满足intent和constraints
  • 怎么让工程不失败？ —— 拆解、验证、迭代

Agent在完成单个具体任务上的能力已经无敌，但我们有前所未有的机遇：一个人能像一个团队一样解决现实世界中的问题。

02 提示词工程

视频地址

提示词

Harness内部 + AGENTS.md + 加载的skills + 你给的指令 + 工具/skills 的调用和输出 = 提示词

  • 提示词工程：一句话怎么写。
  • 上下文工程：每次决策前，哪些token以什么来源、顺序和作用域出现。 AI把“启动尝试”的成本压到很低 —— 立即行动，立即尝试。

疑惑OS：Pi是什么 —— 极简的Coding Harness （

  • 上下文包含了极为复杂的要求，模型被训练为能够不断推进直到满足要求。
  • 越明确且可验证的要求，越可能得到满意的结果。不明确的则模型可能会认为已经“满足”而终止。
  • 做法：
    • 写清楚指令，承担“不明确”可能发生的后果。
    • 压缩合法的解释空间，而不是把品味留给默认值（例如指定前端框架？写明具体的风格、具体的样式和排版）。
    • 明确意图（产品领域知识），把意图变成设计（软件工程） -> 最后将实现交给AI。
  • AI：
    • Pr[token|context]是深度有限的计算，但模型学会了利用上下文思考 - chain-of-thought。
    • 可以同时提出很多要求，AI会想出像人一样逐步逼近目标的过程 - test-time scaling。

每一个token的输出都会“注意”到过去的上下文。适当的时候，下一个chain-of-thought就会纠正错误。 但提示词也会抢夺注意力。

用AI读论文？

  • 短程任务基本上明确指令即可了。
  • 到长程任务：方法论决定了AI的上限。文章的信息密度非常大，AI也会因此被吸收很多注意力、可能被论文作者本身的逻辑带着走。
  • 反直觉：从零开始做产品，AI会从某个时间点开始翻车。但是在大型复杂的软件系统里AI却游刃有余。
    • 代码库本身也是prompt，AI的self-attention会遵循已有的best practice
    • 产品起步时没有建立良好的工程秩序，AI会在slop上不断叠加

We need to do

  • 要对实现的东西有概念，而这只能通过学习获得。要将模型引导到合适的位置上，而学科知识体系里蕴含了很多设计智慧。
  • 少干预，有时反而能做得更多。
  • 希望模型在不确定性中探索 -> AI只会给出有限的方案，因为AI容易认定“已经够了”。
  • 需求不明确，AI给出的方案在一定程度上会趋同 ep. 取名，成为AI时代的zihan。需要思考。

03 软件仓库管理

创造力需要正确的概念和理解 —— 即具有发散和创造能力的前提。

什么是一个软件工程项目？

一个目录 -> 一组文件 -> 一个可交付的东西？ 从U盘到Git，项目版本管理有了标准答案。 课外的信息量和信息密度都很大，但从未被教过如何用好。

关于学习

  • 看到问题，先问自己：我会怎么想？ —— 然后再看作者的做法。如果不一致，正是学习的机会。
  • 读别人的东西要有“感知细节”的意识，学会留意。
  • 举例：推免面试
    • 解释Git，多少能说两句；
    • git rebase，无人回答；
    • git merge冲突后观察到的事项，无人清晰说明
  • 学习的方式是自然地“外推”出去。
  • （OS：原来在git message里写类似 closed #3，GitHub会自动关闭相关Issues）
  • 把关键细节以直观的方式呈现出来。
  • “把细节做好” — “愿意学懂”成了真正有价值的品质

回到软件工程

项目 = 由 Atomic Change 推进的快照，即便AI-native也要避免“一团混沌”。

  • 如果Agent快了1000X，我们该再怎样进行版本控制？

04 软件仓库管理（2）

学习的目的：形成自己的理解

  • 先理解正确的设计，再回望历史，理解一路走来的过程
  • 单个Agent快，Agent还可以并行？ 每个Agent有独立开发计算机，通过Remote同步 -> git worktree

为什么需要版本控制？

  • 人的生产效率有限。
  • 人之间有communication gap，沟通效率低。
  • 人就算沟通了也可能出错。
  • 同样的prompt、同样的模型做同一件事会收敛到相同的结果。

重新思考Fundamental的问题

  • 版本控制只是工具，真正的困难在进度（团队）管理。
  • 如果AI一句话就能做出高质量产品，软件工程就直接死了（斩杀线）。
  • 准则：你的软件能否抵抗需求的变化？
  • ——记住现在（repo）、记住历史（提交的历史演进）、记住教训
  • 用Minimun Viable Product 最小的版本（立即能使用、不完备的版本）验证，评估未来的潜在变化和软件的设计。
  • 早期的Prompt对项目的走向影响最大，可留痕的历史、可用的版本可以帮助你重新梳理架构设计。

05 软件工程的来龙去脉

如果AI能做一个人90%的工作，那个人的注意力就会集中到AI做不好的10%上。

  • 今天的开始一个软件的答案：直接做一个 MVP。
  • 软件工程的诞生
    • 软件工程的需求是高度定制化的，也一直认为是高度需要定制化的。
    • 在成本、时间等约束下，把人的意图变成可工作的软件系统。
    • 瀑布模型：希望迭代只发生在相邻阶段。但实际测试中暴露的问题会一路回溯到设计与需求。
  • 软件工程：为每个阶段都创建方法学和工具，尽可能减少返工的概率。
    • 在没有LLM的时代，不同阶段需要不同的“语言”
      • 需求分析：“我们想要什么”
      • 系统设计：“系统怎样组织”
      • 代码实现
    • 通过定义模型元素和语义，最大程度减少在没有代码时的语义漂移。

06 需求和架构（1）

软件工程的基本观察：需求难对齐、方案难选择、实现与返工贵。

  • Agentic AI：软件生产力的杠杆。现在生产目标明确的代码极为便宜，而需求、产品设计、架构成为撬动软件生产力的杠杆（不认真对待的话，就会成为AI Slop的堆积）。
  • 需求工程：QRCode Generator 需求明确，但公式长且脆弱、需求变更痛苦。
  • CRUD架构：用“当前状态”描述整个系统，为每个需求点写一个状态查询/修改的业务逻辑。
    • 而当前状态 = 历史事实 + 当时适用的规则 + 根据规则做出的决定
    • 可能会产生依赖关系，造成问题
  • 软件是现实世界物理过程的有损投影，系统中会有大量不一致的数据随着时间变成无法解释的黑洞。
  • 系统跑起来后修改的代价极高：数据库迁移、业务逻辑重写。而软件的设计和实现是个手艺活。—— A：数据结构可以记录当前状态和操作历史，状态由replay事件序列决定。

07 需求和架构（2）

软件工程的本质：驾驭复杂性。

  • 需求工程：直面必要的复杂性（需求越完备、歧义越小、管理代价也越大——到今天则是token开销和模型潜在的错误发挥）
  • 架构设计：分解必要的复杂性，减少意外的复杂性。好的架构能更容易实现需求，承受需求的变更。 MVC/CRUD解决了许多业务系统的架构问题，但是没有解决必要的复杂性。

复杂性分解：过去是事实、现在是视图、未来是预期。