学术界和产业界同月交卷：AI 原生 SDLC 的两个答案，撞出了同一个结论

今年八月，软件工程领域有两份重要文件先后落地，一份来自学术圈，一份来自产业界，彼此没有互相引用，却几乎在同一时间给出了同一个诊断。

一份是 8 月初挂上 arXiv 的技术报告《SDAD: Spec-Driven Agentic Development for the AI-Native SDLC》（arXiv:2608.20341），我上周写过一篇精读。另一份是 8 月 21 日 Anthropic 官方博客发布的《The AI-Native SDLC Playbook》，出自 Applied AI 团队的 Louis Claxton 之手，篇幅 46 分钟阅读量，副标题直白得很：如何一个阶段一个阶段地改造你的软件开发生命周期。

我把两份都读完了，越读越觉得这件事值得单独写一篇——不是因为它们观点相近，而是因为论证路径完全不同的两份文件，从两端撞出了同一个结构性结论。这种收敛本身就是信号。

planning

同一个诊断：瓶颈从写代码，移到了写代码的两侧

SDAD 论文的表述是：当智能体能吞下整仓库和完整需求文档，「写代码」不再稀缺，「把意图写清楚」成为新瓶颈，所以生命周期要围绕规约重组。

Anthropic 手册的开篇标题就叫 "Code is no longer the bottleneck"，然后给出了更具体的版图：Build 塌缩到小时级，但左右两侧的 Plan、Review、Test、Deploy 还在以人类速度运转；逐行 review 在人类写代码的时代是合理的控制手段，智能体写掉大部分 diff 之后就跟不上了；治理成本不降反升，异常处理还在走人工委员会。

诊断一致，开出的药方也同构。

处方同构：一根「工件链」，两种表述

SDAD 的核心资产是形式化规约：意图记录 → 机器可读蓝图 → 智能体合成 → 独立验证，人类上游化为 Spec Architect（规约架构师）。

Anthropic 的做法是把这句话落成了具体的文件名。每个阶段以提交一个版本化工件结束、以下一阶段读取它开始：

intent.md → spec.md → plan.md → diff + tests → review findings → incident record

intent.md 记录要解决的问题和约束，产品负责人签发；spec.md 由智能体根据组织级 skills（品牌、安全、合规、UX 政策全部写成技能文件）生成，产品负责人审核但不执笔；plan.md 拆解成有依赖关系的步骤清单；最后到 diff、测试、评审发现、事故记录，每个工件都进版本控制。

手册里有一句很硬的话：这条工件链本身就是审计轨迹。哪个阶段、哪个人、用哪个版本的技能文件批准了什么，git 时间戳全部记得清清楚楚。

再对照角色：SDAD 说工程师要变成「写规约的人」，Anthropic 说产品负责人写 intent.md 和审核 spec.md、技术负责人写 REVIEW.md 和设人工阈值、平台工程师管理技能文件和 hook——双方都在把人类从实现层抽走，钉在门禁上。

三处细节，看出手册比论文更「带血」

论文给框架，手册给的是踩过坑之后的工程细节。三处值得单独说。

第一处：配置也要做回归测试。

CLAUDE.md、skills、hooks 这些「智能体的配置」，一有改动 CI 就自动跑一套真实任务的 eval 套件，通过率跌了就不许合并。思路是把给智能体的配置当成代码对待——配置会过时（模型一升级，旧的判别用例就失效了），所以 eval 必须是活的套件，持续从生产监控里补新 case。甚至规定每出一次生产事故，处理团队要把它写成一条永久 eval。事故不是复盘完就翻篇，而是变成回归测试资产。

第二处：组织级学习闭环。

review 发现同类错误第二次出现，修正直接写进 CLAUDE.md——因为评审也读这个文件，下个 PR 开始这个错误就会被自动拦截。错误处理从「人长了记性」变成「组织长了记性」，而且这个记性是版本控制的。

第三处：看门狗刻意不用模型。

Stage 6 的生产监控，检测脚本完全确定性——滚动窗口统计，一个模型都不调用。分级响应写在配置文件里：轻度偏离只记日志；中度偏离 Claude 以只读身份进场诊断；重度偏离才允许行动，而且行动路线只有白名单——开一个进评审门禁的 PR，或者触发一个预先批准过的 runbook。

为什么检测层要刻意「笨」？手册没明说，但答案很明显：确定性脚本不会幻觉、不会漏报、行为可复现。该笨的地方笨，该聪明的地方聪明——这是把 AI 用在刀刃上的克制。

门禁哲学：两个文本，同一句话

SDAD 论文的结尾是：智能体的速度不会消灭工程纪律，它只是把纪律上游化——转移到规约的精确性、显式的门禁和可审计的溯源里。

Anthropic 手册的收尾是：The loop keeps running. Human judgement stays above it.（循环不停，人类判断悬于其上。）

展开看手册对「门禁」的执行强度：生产部署 hook 在指定发布经理授权前硬阻塞；agent 每次无交互运行用独立身份，流水线日志里「智能体干的」和「工程师触发的」分得清清楚楚；rollback 要求是在 staging 定期演练过的最熟练路径——理由是闭环运行时真的会调用它，必须提前验证过。

手册里还有个细节颇有些微妙的坦白：Stage 5 提到 review 发现本身不批准也不阻塞 PR，分支保护仍然只认 code owner 的批准——但平台工程师如果想在发现数量上设门槛，check run 会输出机器可读的严重度计数。措辞谨慎，留了口子，但方向已经很清楚：人类审批是唯一硬门禁，其他一切是软信号。

差异与短板

两份文件的差异也很清楚。SDAD 停在理论框架和经济学估算——那张 99% 成本塌缩的表数字大胆但来路是作者自估；Anthropic 给的是可执行清单，每个打法都配了能直接从 git 时间戳和 PR metadata 取数的度量指标。

但手册也不是没有盲区。全篇假设读者已经在 Claude Code 生态里，工件链绑定的是 intent.md 这些 Anthropic 格式；46 分钟的篇幅里，对「工件本身过期怎么办」着墨很少——1000 页规约账本和演进了的现实系统之间的一致性，SDAD 论文里那个语焉不详的「规约考古学」问题，在手册里同样没有答案。

为什么说收敛本身是信号

方法论文写作里有个规律：当一个问题真正成熟时，不同出发点的解会趋同。

这一次，学术报告和厂商手册从两端撞出同一句话：代码生成不再是竞争壁垒，工件链和门禁设计的质量才是。

对做智能体开发的人，这两份文件建议都读，顺序无所谓：论文给骨架，手册给肌肉。对准备动手改造团队流程的管理者，直接从手册抄作业，但记住它的隐含前提——你得先把组织政策写成机器可读的技能文件，这一步没有捷径，而且这一步恰好就是 SDAD 说的「新瓶颈」。

钟摆从敏捷摆向规约，这次是学术和产业一起按的手。

参考：

Views: 1

写代码不再是瓶颈：一篇 2026 年新论文如何重画软件开发的生命周期

月初在 arXiv 上刷到一篇技术报告，读完后我在工位上愣了几秒钟——它把我这半年做智能体开发时隐约感到、但一直说不清楚的东西，第一次讲明白了。

论文标题是《SDAD: Spec-Driven Agentic Development for the AI-Native SDLC》（arXiv:2608.20341），2026 年 5 月提交，8 月正式公开。作者名气不大，报告性质、未经同行评审，按理说不值得这么激动。但它干了一件近年来 software engineering 领域很少有人认真做的事：把"AI 智能体到底会怎样重塑软件开发流程"从twitter吐槽和发布会 PPT，拉回到方法论层面严肃讨论。

先说结论：这篇论文的核心主张一句话就能讲完——

当 AI 能一口气读完你的整个代码仓库和需求文档，"写代码"就不再是瓶颈，"把需求写清楚"才是。软件开发的生命周期，将围绕"规约"（Specification）重新组织。

但真正有意思的是它的论证过程。下面挑几个我认为最值得展开的点细说。

code

方法论的钟摆：我们绕了一大圈

论文开篇做了一个历史回顾，视角很刁：把软件方法论七十年的演进读成一个钟摆，在"刚性"和"柔性"两个极点之间摇晃。

1970 到 1990 年代是确定性时代。Royce 提出瀑布模型，RUP 把它体系化，核心信仰是：重文档、重评审、阶段门禁。有意思的是作者考据指出，Royce 本人的原始论文其实强调阶段间反馈和原型验证，比教科书上那条"纯线性瀑布"要灵活得多——是我们把他的图简化成了漫画，然后骂了五十年。

2001 年敏捷宣言接棒，"可工作的软件高于详尽的文档"成为新圣经。Scrum 用两周冲刺把反馈周期从月压缩到周。这个转向在当时完全正确，因为人类把模糊意图翻译成代码的速度太慢了，慢到详尽的前期设计在实现完成前就已经过期。

论文的转折点论证在这里：2025 到 2026 年，前沿模型跨过了一个门槛——上下文窗口从十万 token 进入百万级，智能体可以单次推理吞下整仓库加完整 FRD（功能需求文档），并自主完成跨模块的多文件实现。实证研究记录了 3 到 5 倍的交付速度提升。

问题来了：当"实现"这个环节的耗时趋近于零，之前所有为了弥补"实现慢"而设计的方法论，还成立吗？

作者的答案：敏捷的"轻文档"本质是一种补偿机制，补偿的是人类实现的速度上限。当实现不再稀缺，文档就不再是官僚负担，而是执行的燃料。规约写得越精确，智能体产出越快、越准。

于是钟摆回摆——但不是回到 1970，而是螺旋上升到一个新平衡点：形式化规约 + 智能体高速执行。这就是 SDAD（Spec-Driven Agentic Development，规约驱动的智能体开发）。

模糊性税：需求写得烂，是要交税的

这是全文我最喜欢的概念，因为它把一件工程师们感同身受但从未量化过的事情，变成了一个数学模型。

论文定义：规约清晰度 C 与智能体幻觉概率 H(C) 之间，近似满足指数关系——

H(C) ≈ α·e^(−βC)

清晰度越低，幻觉率不是线性上升，而是指数爆炸。论文配图中划了一条 70% 清晰度的"安全线"，线以下就是"高幻觉区"。

更狠的是"爆炸半径"这个观察：人类时代一个含糊需求，最多害一个模块；智能体时代一句模糊的需求描述，可能在几分钟内被复制传播到几十个文件里，产生系统性的不一致修改。上下文窗口越大，破坏力越强。

由此引出一条我非常认同的工程直觉，论文称之为"智能体线性主义"（Agentic Linearism）：面对一份完整且无歧义的规约，智能体管线以单次不间断的合成通过方式执行时效率最高。中途打断、部分规约、合成途中改需求，都会造成上下文碎片化，输出质量断崖式下跌。

看到这段我笑了。"需求冻结"——这个被敏捷主义者嘲笑二十年的瀑布遗物，居然以"技术优化"的名义复活了。不是官僚惯性，是为了给智能体一个干净的执行上下文。

AI-Code 是第四种生产范式

论文提出了一个分类框架：软件生产历史上出现过三种范式——Pro-code（专业者手写）、Low-code（低代码平台）、No-code（无代码工具），它们区分的本质是"谁写代码、技能门槛多高"。

而 AI-code 完全改变了提问方式。无论你通过 IDE、低代码平台还是无代码工具调用智能体，产出的都是 AI-code——三种入口，同一种产物，同一套治理风险。

AI-code 有三个结构性特征：

第一，作者与责任解耦。生成代码的模型无法被问责，责任只能回溯到下达提示词或批准合并的人类——而大多数组织还没定义这个角色。

第二，表达力与技能脱钩。不会编程的业务人员现在也能生成生产级后端逻辑，No-code 的质量天花板消失了，治理风险的天花板则抬升到了 Pro-code 级别。

第三，范式隐匿合流。以前三种范式产出物不同，IT 部门可以分类审计；现在 AI-code 可以从任何入口产出任何制品，没有生成层的溯源工具就无法审计。

由此，治理的核心问题从"这是谁写的"变成"这是谁规约的、谁评审的、谁批准合并的"。

Spec Architect：软件工程师的新身份

如果代码不再由人写，工程师做什么？论文给出的新角色叫 Spec Architect（规约架构师），要求四种能力：

  • 领域流畅度：深刻理解业务逻辑和系统约束
  • 形式化方法素养：把需求表达为机器可解释的结构（YAML 逻辑、结构化模板）
  • 智能体编排能力：设计多智能体管线——验证智能体、安全审查智能体、回归测试智能体
  • 对抗性推理：预判智能体的失败模式（幻觉、规约漏洞利用），写出对它们免疫的规约

注意第四条，这是最有洞察的一条。以前我们防的是需求理解偏差，现在要防的是"智能体对规约的字面主义利用"——你说"实现登录功能"但没说密码错误几次锁定，智能体就真的不做锁定。写规约变成了一种对抗性博弈。

整个团队都在变形：QA 从写测试用例转向定义评估策略（行为预言、覆盖率契约、回滚标准）；SRE 从跑运维手册转向建设自治控制层（权限边界、智能体行为观测、人类回滚权）；产品经理从写 backlog 转向前置意图精确化——因为智能体会按你写的字面意思执行，歧义不再能在站会上口头澄清。

那张让 CFO 眼睛发亮的表

论文第 11 章给了个示例经济账，比较传统敏捷团队和 SDAD 模式交付同一个复杂模块（规约账本约 1000 页规模）。数字是作者自己的示意性估算，不是审计数据，看个量级：

指标 Human-Agile (2020) Agentic SDAD (2026)
人力投入 480 人时 4 架构师小时
日历时间 4 周（约 2 个冲刺） 15 分钟合成
交付人力成本 ~$48,000 ~$400
Token 计算 — ~$0.20
总实施成本 TCI ~$60,000 ~$600

99% 的成本塌缩。当然要打折扣看——规约本身的撰写成本、验证基础设施、治理开销都被简化了。但趋势方向是对的：当交付的边际成本塌向推理费用，稀缺资源就从"实现人力"迁移到"逻辑清晰度"和"门禁设计"。

配套的量化指标体系也值得记录：TCI 公式引入了迭代乘数 φ（返工倍数），模糊规约通过放大 φ 让成本超线性增长；SER（合成效率比）= 规约的逻辑密度 / 消耗的总 token 数，作为规约架构师的核心 KPI；AAR（智能体自治率）衡量合并代码中智能体生成的占比，高自治 regime 的示意目标超过 95%。

还有一个新概念叫"认知债"（cognitive debt）：仓库里那些行为正确、测试通过、但已经没有任何人类能安全修改的智能体生成代码——必须从规约和测试反推意图才敢动。这是技术债在 AI 时代的变体，而且更隐蔽。

冷静的部分：这篇论文不能照单全收

例行泼几盆冷水。

这是 technical report，未经同行评审，引用的自我循环倾向明显。那个漂亮的 H(C) 指数模型只是"与经验数据一致"的曲线拟合，α、β 的具体数值没有严格估计；3-5 倍加速来自单一研究，作者自己也承认是"方向性证据而非普适因果保证"。第 11 章那张 99% 成本塌缩表，数字标注的是"作者自己的观察性估计"——这在我读过的论文里算是相当大胆的表述方式。

另外，spec-driven development 并非这篇论文首创。2025 年以来 GitHub 的 Spec Kit、AWS 的 Kiro 都在实践这条路，社区对 vibe coding 的反弹更是推波助澜。这篇论文的贡献不是发明，而是系统化的理论包装：钟摆叙事、四范式分类、量化治理指标、四阶段迁移蓝图（评估→试点→混合→SDAD 优先，进展靠门禁赚取而非排期），这个综合框架确实是目前看到的最完整版本。

还有个论文没有充分展开的问题：规约本身会不会变成新的技术债？1000 页的规约账本，谁来维护它与演进了的现实系统之间的一致性？论文提到了"规约考古学"（Specification Archaeology）工具的必要性，但语焉不详。

为什么值得一读

抛开具体框架不谈，这篇论文最有价值的是它把一个正在发生但很少被正面直视的转变讲透了：

过去二十年，软件工程的最佳实践围绕"如何弥补人类实现的局限"展开——小步迭代、口头澄清、恰好够用的文档。接下来十年，最佳实践将围绕"如何榨取机器实现的潜力"展开——前置的精确、机器可读的规约、独立的验证、人类保留的签发权。

论文结尾那句话我抄给了几个朋友：智能体的速度不会消灭工程纪律，它只是把纪律上游化——转移到规约的精确性、显式的门禁和可审计的溯源里。

对做智能体开发的人，这是必读级的方法论镜子；对教软件工程的人，这是 2026 年视角下绝佳的教案素材；对管理者，第 11 章的经济账虽然粗糙，但预算从"交付人头"转向"前沿模型配额 + 治理工具 + 少量规约架构师"的方向判断，值得认真对待。

钟摆还在晃。但这次它停下的位置，看起来跟以往任何一次都不一样。

论文地址：arXiv:2608.20341（CC BY-SA 4.0）

Views: 2

“把 AI 编程的“飞船”换成皮划艇：pi 极简编码智能体实测”

起因：听说有个工具省 token 省得很邪门

前几天听人说，有个叫 pi 的编码智能体，省 token 省得离谱。我心想又是营销号吧，结果动手一搜——搜不出来。搜 "pi" 出来的是圆周率、是树莓派、是某品牌的手机，唯独搜不到这个工具。

后来才知道，作者是故意的。Mario Zechner——写 libGDX 那位，Java 游戏开发圈的传奇——给自己的新项目起了个"完全没法被搜索引擎收录"的名字，还在博客里自嘲：这样就不会有用户，也就不会有人给我提 issue 了。

但 pi.dev 首页那句标语确实戳人：

There are many agent harnesses, but this one is yours.

（世上有许多 agent 框架，但这一把是你自己的。）

抱着"省 token 能省到哪去"的怀疑，我把它装上真刀真枪跑了一圈。结论先放这里：省 token 是真的，而且省得毫无魔法——但它省的方式，可能让被大厂伺候惯了的人一时不适应。

极简到什么程度：系统提示词不到 1000 token

pi 的系统提示词，全文大意就这么多：

You are an expert coding assistant. You help users with coding tasks
by reading files, executing commands, editing code, and writing new files.

Available tools:
- read:  Read file contents
- bash:  Execute bash commands
- edit:  Make surgical edits to files
- write: Create or overwrite files

Guidelines:
- Be concise in your responses
- Use read to examine files before editing
...

对，就这。加上四个工具的参数定义，全部不到 1000 token。

作为对比，我天天在用的 Claude Code，光系统提示词加工具定义，起步就是一万多 token——每开一个新会话，还没说第一句话，一万 token 已经花出去了。pi 把这个起步成本砍到了一个零头。

Mario 的逻辑很暴论但细想有道理：前沿模型被 RL 训练得足够多了，天生就知道怎么当编码 agent，不需要一万 token 的保姆级说明书。这话他也不是空口说的——他带着 pi 用 Claude Opus 4.5 跑了 Terminal-Bench 2.0，跟 Codex、Cursor、Windsurf 这些重型选手同台，成绩排在前列。

实测：给真活干，看它怎么花钱

光看宣传没用。我给它派了个真实任务：一段有除零 bug 的 JS 代码，要求修复、写测试、跑通验证。

它的整个工作过程：5 次工具调用（read ×1、edit ×1、write ×1、bash ×2），6 轮模型请求，然后交卷：

输入 token: 1,593（非缓存）
输出 token: 1,087
缓存读:    19,520

说实话看到这个账单我愣了一下。这个数字里最值得玩味的是"非缓存输入"那一栏——整个任务真正新烧的输入 token 还不到 1600。pi 的省不是什么黑科技，是结构性的：系统提示词小、工具少、没有背着你塞进上下文的隐藏内容。你看到的就是模型看到的，花出去的每一个 token 都摆在明面上。

顺带一提，它对国产模型的亲和度意外地好。内置 zai 提供商，检测到我环境变量里的 ZAI_API_KEY 就直接认了，GLM-5.3-flash 开箱即用，上下文窗口直接给到 1M。装完第一次跑就成功返回，零配置。

踩坑三连（这部分最值钱）

安装五分钟就完事了，但配置踩了三个坑，全记在这里：

坑一：defaultModel 写了等于没写

我最初在 settings.json 里这样写：

{ "defaultModel": "zai/glm-5.3-flash" }

结果被静默忽略，不报错、不警告，就是不理你。正确姿势是两个键分开写：

{ "defaultProvider": "zai", "defaultModel": "glm-5.3-flash" }

这个格式要求藏在文档一行表格里，踩之前谁能想到。

坑二：一场 403 侦探剧

修好坑一以后依然 403："Request not allowed"。诡异的是，命令行显式指定 --model 就一切正常，走默认配置就挂。

排查下来发现案中有案：我机器上有一组给 Claude Code 用的环境变量（ANTHROPIC_BASE_URL 指向 bigmodel 的 GLM 接入点）。pi 一看环境：哟，有 Anthropic 凭证，那默认走 Anthropic 家——于是拿着 GLM 的钥匙跑去 bigmodel 门口点名要 claude-opus-4-8，保安当场拦下。

把这组变量从环境里摘掉，立刻正常。教训：装了 pi 就把 defaultProvider 显式钉死，千万别让它自己猜。

坑三：证书报错连击

首次运行时 pi 想现场下载 ripgrep 和 fd 两个搜索工具，在我的网络环境下双双 TLS 证书报错。解法朴素得感人：

scoop install ripgrep fd

装完 pi 自己就在 PATH 里找到了它们，下载逻辑根本不触发。

它的哲学，你敢不敢用

pi 最有争议的不是功能少，而是它把几件事做绝了：

YOLO 模式是唯一模式。 没有权限确认弹窗，没有"允许此命令吗"，文件直接改、命令直接跑。Mario 的说法是：一个能写代码又能执行代码的 agent，加那些确认框属于安全剧场——真想搞破坏的路子多了去了。我承认他说得有道理，但第一次看它毫无心理负担地改我文件的时候，还是倒吸了一口凉气。介意的话官方文档给了容器化方案，建议真的用起来。

拒绝 MCP。 理由很"token 感性"：Playwright MCP 21 个工具的描述就是 13.7k token，Chrome DevTools MCP 26 个工具 18k token——还没开始干活，上下文先烧掉 7-9%。pi 的替代方案是"CLI 工具 + README"：agent 需要时自己去读文档，用不到就不付钱。渐进式披露，这才是对上下文窗口的尊重。

"子代理是计划不足的症状。" 这是全书最暴论的暴论。他的观点：会话中途开子代理去收集上下文，说明你一开始就没规划好；正确姿势是单开一个会话把上下文整理成文档，再带着干净的上下文开工。我同意一半——上下文污染确实是大问题；但大型代码库里"先通读一遍"的成本也不低。这条见仁见智。

没有 todo 列表、没有 plan 模式。 需要就写 TODO.md、PLAN.md，让 agent 自己读写。文件即状态，跨会话可版本管理，比藏在运行时内存里的易失状态实在多了。

结论：适合谁

适合你，如果：你心疼 token、想完全掌控模型上下文、用订阅制模型（Claude Pro/Max、GLM Coding Plan 都能直连）、并且愿意花半小时按自己的口味改造工具——pi 的扩展是 TypeScript 模块，官方哲学就是"缺什么，让 pi 自己给自己写一个"。

不适合你，如果：你要开箱即用的安全护栏、离不开 MCP 生态，或者想到 AI 在工作目录里裸奔就睡不着觉。

至于我：Claude Code 还会继续用，但 pi 已经常驻了。一个是全副武装的飞船，一叶随身的皮划艇——远洋当然飞船稳，但去楼下便利店买瓶水，你真不想发动那台飞船。

想试的从 pi.dev 开始，五分钟能跑起来。记得先把 defaultProvider 钉死。

Views: 3

软件工程还值得学吗：这一年我在课堂内外看到的真相

又到毕业季，学生问得最多的一句话是："老师，软件工程还值不值得学？"

我不打算给标准答案。先把这一年我在课堂内外看到的东西摆出来，再说我的判断。

掌舵的人已经把话挑明了

去年一月，扎克伯格在 Joe Rogan 的播客里说：2025 年，AI 将能够胜任公司里中级工程师的工作。这不是 futurist 写科幻，是 Meta 的 CEO 在向投资人交代人力成本的走向。

差不多同期，Anthropic 的 CEO 达里奥·阿莫代在公开场合预测，AI 会消灭相当比例的初级白领岗位。Salesforce 的贝尼奥夫说得更直白：他们公司相当一部分工作量已经由 AI 承担。

信不信是另一回事，但写代码这件事的稀缺性定价在往下走，是所有数据源共同的指向。GitHub 的调查里，使用 AI 辅助工具的开发者比例早已过半；国内招聘平台上，纯"增删改查"岗位的供给连续收缩，而 AI 应用开发、大模型工程化方向的岗位在逆势增长。

一句话总结现在的行情：总量在缩，门槛在抬，但塔尖和特定方向的口子反而张大了。

一个就在眼前的真实样本

不举远处的大厂例子，说说我自己干的事。

这两年我自己搭了一套课堂在线测验系统。不是外包的，不是买的，从需求分析到数据库设计到前端页面，自己一行行磨出来的。为什么一个教书的人要干这个？因为我发现"随堂测验—自动批改—错题统计"这件事，市面上的工具要么贵、要么不合教学场景，这就是一个真实的麻烦。

磨这个系统的过程中，我踩的坑比写十门课的作业都多：高并发提交怎么扛、防作弊怎么做、试卷数据怎么设计才不至于每加一个题型就重构一次。这些坑，恰恰是教科书里没有、面试官最爱问的东西。

后来我把这套系统用到真实课堂，几百个学生真实地用过、骂过、也真香过。这个完整的过程——发现麻烦、定义需求、选型、踩坑、上线、迭代——就是我理解里"软件工程"四个字的全部含义。

而这件事本身也说明：AI 时代并没有取消"做东西"的机会，反而把做东西的门槛降低了。 现在有大模型帮你写样板代码、查文档、 debug，一个普通人做出一个能用的系统的成本，比五年前低了一个数量级。问题只剩一个：你有没有一个真实的麻烦想去解决。

所以，到底还值不值得学

我的答案是：值得，但值得的姿势变了。

第一，"会写代码"的溢价在归零，"会做东西"的溢价在涨。 课程设计和真实项目的差距，不在于代码量，在于有没有真实用户、真实反馈、真实故障。趁早找一个真实的麻烦去解决——社团的、家里的、小店的都行。别嫌问题小，小才有机会做完整个闭环。

第二，把 AI 当锤子，别当对手。 焦虑"AI 会不会取代我"没有意义，有意义的是"我的产出里有多少是 AI 放大的"。现在面试已经出现新题型：给一个需求，允许用任何 AI 工具，限时看结果。习惯一个人硬啃的学生，在这种场合反而吃亏。

第三，地基别偷工减料。 数据结构、操作系统、计算机网络、数据库，这老四样在 AI 时代更值钱了。AI 能替你写代码，替不了你判断代码对不对、错在哪、为什么慢。面试官筛人，筛的就是"代码能跑但讲不出为什么"的那种。

第四，第一份工作是进站台，不是终点站。 死守"非大厂不去"，把应届生身份耗在等待里，是我见过最亏的决策。先进场，在真实工程环境里泡两三年，那身本事是带得走的。行业有周期，人生是长跑。

第五，实习是硬通货。 秋招简历筛选的铁律没变过：一段对口实习，顶半页奖项。

结尾

技术永远在变，岗位永远在洗牌。但"发现一个真实的麻烦，然后把它漂亮地解决掉"这件事，从图灵的时代到现在，就没有贬值过。

工具越强大，会用工具解决真实问题的人就越值钱。

与学生共勉。

Views: 21