超级个体真有那么神吗

一个更老的问题：全才，还是半吊子？

现在的“超级个体”，看起来有点吓人。

上午用 Python 搭一个 AI agent，午饭前让 Go 服务跑起来，下午改 React 页面，顺手补一段 Java 后端逻辑。晚上再看一眼 C++ 崩溃栈，调个 WebRTC 视频马赛克问题，顺便让 AI 帮忙扫一下权限漏洞。要是还有力气，再把 iOS/Android 的适配问题捎带看了。

乍一看，这哪是程序员，简直像开了多线程外挂。

可是人类对这种人并不陌生。古人早就见过两类“什么都会”的人。

一类是“样样精通，样样稀松”。嘴上能讲，纸上能写，真上场就露馅。英文里有句老话叫 Jack of all trades, master of none，中文说得更狠：万金油，哪里都能抹一点，哪里都不治病。

另一类是真全才。达·芬奇可以画画、解剖、研究机械和水利；沈括能写《梦溪笔谈》，横跨天文、地理、数学、工程和自然观察；富兰克林从印刷、写作、发明、电学实验一路做到外交；玛丽·萨默维尔能把天文学、物理、地理、数学写成影响一代科学家的综合作品。

所以问题不是“有没有全才”。当然有。

真正的问题是：

AI 时代，一个普通但勤奋的工程师，能不能借助 AI 变成靠谱的跨域全才？还是只会变成更会包装的半吊子？

我的答案比较不讨喜：AI 可以让你更快跨域，但不会自动让你变深；它可以把一个人变得像一支小队，但不能替你承担工程责任。

更贴切的反例：南慕容遇上北乔峰

历史和文学里，“懂很多”和“能亲自负责”常常是两回事。

王语嫣当然是一个好比喻。

她熟读各派武学秘籍，能看出招式来路，也能指出破绽。别人一出手，她大概知道是哪门哪派、下一招可能怎么变。这个能力很厉害，绝不是无用。

但她的问题是：她基本不自己动手。

拿她来比 AI 时代的“超级个体”，稍微有点偏。今天很多跨域工程师不是坐在旁边点评，他们确实会写代码、会搭系统、会救火，也真的能交付一些东西。危险不在于完全不会动手，而在于把“会很多招式”误认成“有自己的真功夫”。

所以更贴切的例子，是《天龙八部》里的慕容复。

慕容复不是草包。他出身姑苏慕容，家传绝学“斗转星移”，江湖上有“以彼之道，还施彼身”的名声，还能与乔峰并称“北乔峰，南慕容”。这不是普通人的江湖履历，这是顶级简历。

他也确实亲自下场。少室山一役并不是一场规规矩矩的擂台单挑，场面更像真实工程事故：多人混战，变量横飞，名声、传闻、战术和心态全搅在一起。慕容复能打，也会借力打力，可到了关键处，和乔峰一比，差距还是露出来了。

这场戏最有意思的地方，不是“慕容复一点本事没有”。恰恰相反，他有本事，有资源，有名声，也有很多招。问题是，他的主轴太散，心气太乱，很多能力像借来的、拼起来的、为了一个虚妄目标服务的。

乔峰就不一样。

乔峰未必会天下所有武功，也不靠招式花样取胜。他厉害在根基、实战、判断和担当。降龙十八掌看起来不复杂，但被他练到能在关键时刻硬生生扛住局面。说白了，他不是“什么都知道一点”，而是有一两门东西已经长进骨头里。

这对 AI 时代的程序员很有启发。

慕容复式工程师也不少见。他能让 AI 给出十种架构模式，能背出 CAP、DDD、CQRS、SAGA，能把 C++、Go、Rust、Java、Python 的优缺点讲成一张漂亮表格。可真让他修一个线上内存泄漏、设计一个权限模型、排查一次音视频弱网马赛克，他开始说：“这个问题比较复杂，需要系统性分析。”

这句话没错。只是很多时候，它的潜台词是：我没有主轴，我没有证据，我也没准备好负责。

“样样精通，样样稀松”的本质，不是学得太多，而是只有招式库存，没有实战闭环；只有借招能力，没有负责能力。

“什么都会”和“只会一样”，差别在哪里？

文学和武侠里，其实早就把这件事写透了。

“什么都会”不一定坏，“只会一样”也不一定窄。关键要看：这些能力有没有经过实战熔炼，最后有没有长成自己的东西。

王语嫣和百晓生像今天的知识库、排行榜和 benchmark。它们很有用，能帮你少踩坑，能让你知道江湖上有哪些门派。但它们不是最终答案。排行榜不能替你上线，知识库不能替你背锅。

慕容复和鸠摩智更像另一类人：他们不是不会，他们是真会。只是会得太多、求得太急，最后很多东西没有长成自己的根。放到技术世界，就是组件会拼，架构会画，名词会讲，demo 会跑，可一到生产事故，才发现没有一条能力链路能完整闭环。

杨过就不一样。他学过古墓派、全真、欧阳锋、洪七公、黄药师，也受独孤求败一路影响。可他最后没有变成“武学收藏夹”，而是把这些东西连同自己的遭遇、身体限制和心境，化成了自己的黯然销魂掌。这才叫融会贯通：不是把资料都放进收藏夹，而是长出新的能力。

乔峰和李寻欢则提醒我们，专精并不是落后。乔峰未必招式最多，但一掌推出去，背后是根基、胆识和战场经验。李寻欢的小李飞刀也不是“只会扔刀”这么简单，它背后是时机、判断、克制和人格。真正的一门入化，往往已经不是一门技术，而是一整套做人做事的方法。

所以，别把“广”和“深”简单对立起来。

工程师最理想的状态，不是只守一门，也不是满桌 sample code；而是先有一两处能扛事的深根，再把其他领域接上来。广度负责发现连接，深度负责承担后果。

再看真全才：他们不是平均用力

真正的全才，并不是每个领域都浅浅摸一下。

他们有几个共同点：有深根，有项目，有记录，有反馈，有时代窗口。

达·芬奇不是今天看一篇解剖学，明天问 AI 画一架飞行器。他长期画、长期观察、长期记笔记。Britannica 对他的介绍里特别强调，他的艺术和科学并不是分开的两摊，而是由观察、绘图和对自然结构的追问连接起来。

沈括也不是“兴趣爱好广泛”这么简单。《梦溪笔谈》里那些天文、地理、工程和自然观察，很多来自实际职务、仪器测量和对异常现象的追问。换句话说，他不是坐在书房里做百科摘抄，而是在真实问题里不断校准自己的知识。

富兰克林更像一个早期的“社会工程师”。印刷让他掌握传播，写作让他影响公共舆论，电学实验让他进入科学共同体，公共事务和外交又让他把知识变成制度和资源。

玛丽·萨默维尔则提醒我们：全才不一定都表现为“我亲手发明一切”。她的能力在于综合与表达。她把数学、天文学、物理、地理等领域连接起来，让复杂科学变得可理解。对 AI 时代的工程师来说，这一点特别要紧：能把跨域知识讲清楚、组织好，本身就是高级能力。

这些人都不是“平均主义全能”。

他们更像一棵树：根扎得很深，枝条伸得很远。枝条之所以不乱飞，是因为根还在。

真全才是怎么做到的？

如果把这些人抽象成方法，我看到五条。

1. 他们都有一个主轴

达·芬奇的主轴是观察和图像表达。沈括的主轴是对自然、制度和技术的实证记录。富兰克林的主轴是实用主义：什么能改善生活、组织社会、推动公共事务，他就去做。玛丽·萨默维尔的主轴是数学化理解和科学综合。

主轴很重要。

没有主轴的跨域，是逛商场；有主轴的跨域，是修铁路。前者看了很多，后者能把东西运起来。

工程师也是一样。你可以学很多语言，但最好有一个主轴：后端系统、RTC、AI 工程、安全架构、基础设施、数据平台、移动端体验，至少要有一两个深水区。

否则你会变成“技术旅行博主”：每个地方都打过卡，没有一个地方能带队。

2. 他们用项目牵引学习

真正的能力不是靠“我学过”长出来的，而是靠“我做成过、做砸过、修回来过”长出来的。

达·芬奇研究机械，不是为了攒知识点；他要解决绘画、建筑、军事、城市和水利问题。沈括的很多观察来自实际治理和技术事务。富兰克林的发明和公共组织，都有很强的现实用途。

这对 AI 时代尤其重要。

不要问：“我是不是该学 Rust、Go、TypeScript、Swift、Kotlin、C++20？”

更好的问法是：“我现在要做一个什么项目，逼自己把这些知识串起来？”

3. 他们有自己的笔记系统

达·芬奇留下大量笔记和图稿。《梦溪笔谈》本身就是一种高密度知识记录。富兰克林写作、办报、通信、组织社团。玛丽·萨默维尔则把复杂科学整理成体系化著作。

全才不是脑容量大到可以随便装。

全才往往都有外部记忆系统：笔记、草图、书信、论文、实验记录、索引、案例库。

今天的工程师也是一样。靠脑子硬记 C++、Go、Java、Python、前端、安全、音视频、移动端，迟早会把自己熬成一个人肉缓存，还没有 LRU 策略。

4. 他们愿意接受现实反馈

真正的全才不怕被现实打脸。

画不像，就继续观察；仪器不准，就改测量方法；实验失败，就换假设；公共政策推不动，就调整联盟和叙事。

“样样精通，样样稀松”的人最怕反馈。他喜欢讨论，讨厌验收；喜欢方案，讨厌事故；喜欢说“从原则上讲”，讨厌上线后的报警。

工程能力最后一定要被这些东西验收：

• 测试能不能过；
• 线上能不能扛；
• 用户能不能用；
• 事故能不能复盘；
• 代码三个月后别人敢不敢改；
• 安全边界能不能经得起恶意输入。

没有验收的全能，只是简历排版。

5. 他们知道自己不是每件事都亲自做到顶

这点很反直觉。

很多全才并不是每个领域都做到世界第一。他们厉害在于能建立连接、判断轻重、组织资源、提出问题、理解多种语言之间的转换。

这恰恰是 AI 时代最重要的能力。

你不一定要亲自成为 C++、Go、Python、Java、React、iOS、Android、Security、WebRTC 每个领域的 L3 专家。你需要知道：哪些地方自己能负责，哪些地方只够沟通，哪些地方必须找真正专家。

一通百通，也要一处一处过细节

就程序员这个范畴来说，很多东西确实是共通的。

数据结构、算法、设计模式、网络协议、并发控制、资源管理、缓存、队列、状态机、抽象边界、错误处理、可观测性、安全边界……这些不是某一种语言的私产，而是软件世界的基本骨架。

你写 Java 会遇到生命周期和并发，写 Go 也会遇到；你做前端要管理状态，做后端也要管理状态；你做 WebRTC 要在延迟、丢包、带宽之间取舍，做分布式系统也要在一致性、可用性、性能之间取舍。名字不同，底层矛盾很像。

所以，掌握学习方法、做人做事的方法、沟通方法，对新知识的触类旁通绝对有帮助。

会学习的人进入新领域，不是从“背 API”开始，而是先问：

• 这个领域的核心对象是什么？
• 数据怎么流动，状态在哪里变化？
• 资源谁创建，谁释放，谁负责失败恢复？
• 正常路径是什么，异常路径是什么？
• 哪些指标能说明它真的工作正常？
• 这个领域最常见的事故长什么样？

问到这些问题，就已经不是普通新手了。

但软件行业还有一句更残酷的老话：魔鬼藏在细节里。

第一性原理可以让你少走弯路，不能替你把小路上的坑填平。你可以很快理解一个领域的主干，但只要在关键细节上不拘小节，工程世界会用很贵的方式提醒你：产线故障、用户投诉、老板追问、同事埋怨，一个都不会少。

比如：

所以，“一通百通”不是免考金牌。

更准确地说，它有三层含义：

第一，见自己。知道自己的主轴在哪里，知道哪些能力是真功夫，哪些只是 AI 扶着走了两步。

第二，见众生。看见不同领域的共同困境：复杂度、资源、状态、失败、协作、信任边界。你会发现，程序员每天换技术栈，本质上还是在和这些老问题过招。

第三，见天地。看见技术背后的规律和限制：没有免费的抽象，没有免费的性能，没有免费的安全，没有不需要验收的正确性。

到了这一层，确实可以“众采百家之长，融会贯通，别开生面”。

但别忘了最后半句：融会贯通之后，还要落到证据、作品和责任。

否则所谓第一性原理，很容易变成高级版纸上谈兵。

那 AI 到底是什么：外挂、工具，还是大杀器？

我觉得这三个说法都对，但层级不同。

第一层：AI 是外挂

在入门和样板阶段，AI 确实像外挂。

过去查 API、搭 demo、写样板、读陌生代码，要花很多时间。现在一句 prompt 下去，代码、解释、测试、文档都有了。一个后端工程师能快速碰前端，一个 Java 工程师能读 Go，一个做业务的人能写日志分析脚本。

这很像游戏里开了加速器。

但外挂有个问题：它会让你误判自己的真实水平。

AI 帮你写出来，不等于你会；AI 讲得顺，不等于它对；AI 让测试绿了，不等于场景全覆盖。用外挂最怕的不是赢得太快，而是忘了自己为什么能赢。

第二层：AI 是工具

进入工程阶段，AI 必须从外挂降级为工具。

工具要进流程，要有边界，要被验证。

比如：

• AI 写代码，但 CI、单元测试、集成测试要卡住；
• AI 解释日志，但最终假设要靠数据证明；
• AI 生成安全 checklist，但高风险决策要有人审；
• AI 写文档，但文档要标明来源、适用范围和验证状态；
• AI 生成架构草案，但人要决定取舍、成本和责任。

这时候 AI 不再是“神奇按钮”，而是工程工具链的一部分。

你信的不是 AI，你信的是围绕 AI 建起来的验收系统。

第三层：AI 是一种新型大杀器

再往深处看，AI 又确实不只是普通工具。

它改变了跨域的交易成本。

以前一个人从后端跨到前端，从 Java 跨到 Go，从业务跨到安全，从 WebRTC stats 跨到可视化工具，中间有很多门槛：术语、环境、样板、文档、调试、搜索。AI 把这些门槛砍掉了一大截。

这意味着什么？

意味着一个人的“可尝试范围”变大了。

过去你可能不会动手做一个内部工具，因为要写前端、后端、部署、文档、权限，想想就累。现在 AI 可以帮你把粗活打掉。你真正要花时间的，是定义问题、设计边界、验收结果。

这就是大杀器的地方：AI 不是单纯提高写代码速度，而是在重写一个人的能力边界。

不过，大杀器也有后坐力。

它会把你的判断缺陷放大，把你的需求模糊放大，把你的验证懒惰放大。你原来想不清楚，只是慢慢错；现在想不清楚，是高速错。

超级个体的正确姿势：梳子型能力

我不太相信“一个人每个领域都很深”的神话。

更靠谱的模型是梳子型能力：

• 1 到 2 个领域做到 L3：能负责到底；
• 3 到 5 个领域做到 L2：能在清晰边界内独立交付；
• 更多领域做到 L1：能读懂、沟通、定位问题域；
• 所有高风险领域都知道何时找专家。

这比“全栈”这个词更诚实。

L1：读得懂

能借助 AI 和文档理解代码、日志、错误信息，能判断大概问题域，能跟专家对话。

比如：

• 能读懂一段 Swift/Android 崩溃栈，知道可能跟生命周期或权限有关；
• 能看懂 WebRTC stats，知道 RTT、jitter、packet loss 分别指向什么；
• 能理解 Java 鉴权代码，知道 token、session、permission check 在哪里；
• 能读懂 C++ 编译错误，知道 template 报错大概从哪里开始看。

L1 的价值是打通沟通，不是独立签字。

L2：改得动

能在清晰边界内做修改，能写测试，能跑验证，能解释自己的改动。

比如：

• 给 Go 服务加一个 API，并补上单元测试和错误处理；
• 改一个前端表单交互，同时确认状态、校验、失败提示和埋点；
• 写一个 Python 脚本分析日志，并让输出可复现；
• 修一个 C++ 小模块的资源释放问题，用 sanitizer 验证；
• 给 WebRTC stats analyzer 增加一个指标，不顺手发明诊断结论。

L2 是 AI 时代很实用的能力。很多超级个体的高产，主要来自把多个领域推进到 L2。

L3：扛得住

出了生产事故、性能问题、安全风险、架构后果，你能负责到底。

比如：

• 你设计的权限模型能经得起绕过、越权、审计和回滚；
• 你改的 C++ native 层在崩溃、内存、性能上能被验证；
• 你调的音视频策略能解释弱网、设备、CPU 和用户感知之间的取舍；
• 你负责的后端服务能讲清楚容量、故障域、降级、监控和报警；
• 你做的移动端能力能覆盖权限、后台行为、系统版本和灰度策略。

L3 不靠 prompt，靠长期训练、真实事故、系统理解和责任意识。

一个健康的超级个体，应该像梳子一样：一两根齿很深，几根齿中等，很多齿能浅浅插进去。不要幻想每一根齿都扎到地心。那不是超级个体，那是自我感动。

一个具体场景：一个人做 AI 产品，哪里能全能，哪里不能

假设一个超级个体要做一个 AI 辅助的协作工具。

它需要：

• 前端页面：上传文件、展示分析结果、聊天交互；
• 后端 API：用户、任务、权限、文件处理；
• Python agent：调用模型、解析文档、生成结果；
• Go worker：异步任务、队列消费、状态更新；
• 数据库：任务状态、用户配置、审计日志；
• 安全：鉴权、文件类型检查、日志脱敏、权限隔离；
• 移动端：也许还要做一个轻量 iOS/Android 入口；
• 音视频：如果有会议录音、转写、片段分析，还要处理媒体文件。

在 AI 加持下，一个人能不能做？

能做出第一版，而且速度会比以前快很多。

AI 可以帮他生成前端组件、API skeleton、数据库 migration、Python 解析脚本、Go worker、Dockerfile、README、测试样例。一个人把产品从 0 推到 1，今天确实比过去现实得多。

但它不能跳过几条线。

第一，权限模型不能糊。谁能看谁的文件，谁能下载，谁能删除，分享链接如何过期，审计日志怎么保留，这些不能靠“AI 觉得差不多”。

第二，文件处理不能糊。上传类型、大小限制、病毒扫描、解析失败、临时文件清理、敏感内容泄露，都要有边界。

第三，AI 输出不能糊。模型生成的总结有没有来源，是否标记不确定性，是否能追溯到原文，用户能不能纠错，这些决定产品可信度。

第四，移动端和音视频不能糊。权限弹窗、后台行为、设备差异、媒体格式、转码失败，都是“demo 没问题，生产就热闹”的典型来源。

所以结论是：超级个体可以把很多事串起来，但要清楚哪些地方只是原型能力，哪些地方已经进入生产责任。

能串起来，是能力；知道哪里不能硬扛，是成熟。

最高优先级：交付价值，不是证明自己会武功

说到这里，还要把话收回来。

我们讨论“超级个体”、跨域能力、AI 工具链、L1/L2/L3，不是为了把工程师训练成技术杂技演员。终极目的仍然很朴素：向用户交付有价值的产品。

敏捷宣言背后的十二条原则，第一条就讲得很直白：最高优先级是通过尽早和持续交付有价值的软件来满足客户。

这句话放到 AI 时代，反而更有分量。

AI 让我们更容易写代码，也更容易写出一堆没人用的代码；更容易搭 demo，也更容易把 demo 包装成产品；更容易画架构图，也更容易过度工程，把一个本来两周能验证的需求，做成三个月还没有用户反馈的平台。

炫技没有错，但炫技不是交付。

工程质量很重要，但工程质量也不是拿来供奉的。测试、监控、安全、回滚、架构边界，最终都要服务于一件事：让用户稳定地获得价值，让团队可以持续交付，让产品有机会创造利润。

利润这个词也不用不好意思。没有用户价值，就没有收入；没有收入，就没有持续投入；没有持续投入，再漂亮的技术栈也只是展厅里的兵器。

我更愿意这样区分几类超级个体：

这不是说可以粗糙。

恰恰相反，真正的价值交付要求你更清醒：哪些地方要快，哪些地方不能省；哪些地方先做薄，哪些地方必须做硬；哪些功能只是好看，哪些功能用户今天真的愿意用、愿意付费、愿意推荐给别人。

最高明的功夫，不是把所有招式都打一遍，而是在关键时刻用最合适的一招解决问题。

怎样避免变成 AI 时代的“南慕容”

AI 让人容易变成“技术南慕容”。

以前闯江湖靠门派、秘笈、兵器谱和传闻；现在扩展技术面靠 prompt、sample code、架构图、排行榜和漂亮 demo。形式升级了，风险没变：离真实反馈太远。

要避免这个坑，我建议六件事。

1. 先写清用户价值

每个项目开始前，先用几句话写清楚：

• 用户是谁？
• 他现在有什么痛点？
• 我们交付什么能力能让他更省时间、更少出错、更愿意继续用？
• 这个能力如何验证？
• 它有没有可能创造收入、降低成本、提高留存或减少风险？

如果这些问题答不上来，先别急着选技术栈。

没有用户价值的跨域，只是技术旅游；没有商业闭环的多产，只是库存积压。

2. 每个领域标责任等级

给自己的技术面画一张能力地图，不要只写“会”，要写到哪一层。

这张表不是给别人看的，是给自己降温的。

3. 每个领域保留最小演练

知识是否生锈，不是靠感觉判断，而是靠演练判断。

• C++：写一个 RAII wrapper，用 sanitizer 找一个内存问题；
• Go：写一个带 context cancel 的 worker pool；
• Python：写一个日志分析 CLI，并加上测试；
• Java：写一个权限校验小例子，覆盖允许、拒绝、越权；
• 前端：写一个表单页面，用 Playwright 跑 smoke test；
• Audio/Video：解析 WebRTC stats，标记 jitter 和 packet loss 异常段；
• Security：做一次输入、鉴权、日志、依赖的 checklist review；
• iOS/Android：读一次崩溃栈，定位到生命周期或权限问题。

看十篇文章，不如跑一次 sanitizer；听三小时课程，不如亲手写一个最小复现。

4. 把 AI 产出接到验收系统

AI 生成代码后，必须接入验证。

• 能不能跑起来？
• 有没有测试？
• 有没有失败路径？
• 有没有日志和指标？
• 有没有安全边界？
• 有没有回滚方案？
• 有没有说明哪些地方没验证？

尤其是安全、支付、隐私、权限、音视频核心链路、移动端发布、数据迁移这些地方，不要用自信填空。

5. 保留自己的知识索引

超级个体的多产，不是脑子里装了所有细节，而是有一套需要时能迅速召回的索引系统。

knowledge-lab/
  cpp/
    crash-debugging.md
    ownership-kata/
    sanitizer-notes.md
  go/
    context-cancel.md
    api-template/
    pprof-notes.md
  python-ai/
    agent-eval-template.md
    prompt-patterns.md
    log-analysis-tools/
  frontend/
    form-patterns.md
    playwright-smoke/
  av/
    webrtc-stats.md
    jitter-casebook.md
  security/
    authz-checklist.md
    logging-redaction.md
  mobile/
    permission-casebook.md
    crash-symbolication.md

这不是为了收藏资料，而是为了让下一次恢复更快。

6. 找人，而不是装神

超级个体不是孤岛。

AI 再强，也不能替代真实专家的经验密度。遇到高风险问题，找人 review、pair、challenge，一点都不丢人。

真正丢人的是明明只到 L1，硬装 L3。

小结：AI 时代，全才更可能，也更危险

历史上的全才告诉我们：跨域能力是真实存在的。

文学和历史里的反例也提醒我们：会背、会说、会包装，不等于能打。

AI 把跨域门槛大幅降低了。它像外挂，因为它让你快；它像工具，因为它必须接入流程；它也像大杀器，因为它正在改写一个人的可尝试范围。

但最后那条线没有变：

AI 可以让一个人像一支小队，但不能让一个人逃掉工程责任。

还要再加一条：

工程能力的最终验收，不是你懂多少技术，而是你能不能持续交付有价值的产品。

真正靠谱的超级个体，不是“我什么都会”，而是“我知道自己每个方向到哪一层，也知道这些能力要服务哪个用户、解决哪个问题、创造什么价值”。哪些是 L1，只能读懂和沟通；哪些是 L2，可以独立修改和验证；哪些是 L3，出了事能负责到底。

别怕技术面变宽。该怕的是技术面变宽以后，自己还用“我都懂一点”来安慰自己。

南慕容也懂很多，也会很多。

问题是，真到了少室山，江湖只看你能不能接住这一掌。

行动清单

• [ ] 每个项目先写清用户、痛点、价值、验证方式和商业结果。
• [ ] 给自己的技术面画一张能力地图，把每个领域标成 L1 / L2 / L3。
• [ ] 挑 1 到 2 个领域做 L3 深水区，不要幻想每个方向都深。
• [ ] 每周做一个 60 分钟硬技能练习，必须有可运行结果或可验证输出。
• [ ] 每月做一个跨域小项目，训练接口处的判断力。
• [ ] 对高风险领域设置硬边界：安全、权限、隐私、数据迁移、媒体核心链路、移动端发布，必须有人审、有证据、有回滚。
• [ ] 让 AI 帮你出题、搭架子、写样板，但最终验收标准由用户价值和工程证据来定。

参考资料

• Leonardo da Vinci - Britannica
• Dream Pool Essays - Internet Archive
• Benjamin Franklin - Britannica
• Mary Somerville - Britannica
• Principles behind the Agile Manifesto
• 慕容复 - Wikipedia
• 黯然销魂掌 - Wikipedia
• 李寻欢 - Wikipedia

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。