2026-3
目录
12
当 AI 写了几乎所有代码，软件工程会怎样？（摘）
- 宝玉的翻译转载：https://weread.qq.com/web/mp/reader/077424a224d505f5758535f33393537383132343438dfd
- Gergely Orosz原文：https://newsletter.pragmaticengineer.com/p/when-ai-writes-almost-all-code-what?ref=blog.pragmaticengineer.com
"你不能因为那些粗制滥造和让人尴尬的 AI 输出就否定 AI 本身的了不起。这是自从我们把计算机联网以来，最让人兴奋的事。如果你 2025 年一直在对 AI 悲观或怀疑，为什么不在 2026 年带着乐观和好奇心重新开始呢？
产品管理 vs 软件工程：融合还是分离？ 产品经理现在可以更容易地生成软件——实现目标所需的工程师更少了——但软件工程师同样不那么需要产品经理了。两个职业的重叠将比以往更多。
执行定义清晰的工单（ticket）将越来越多地由 AI 完成。
技能全面的软件工程师更受欢迎
- 定义清晰的工单需要由软件工程师来编写
- 有产品思维
- 能构建好的架构。能够构建可靠、高性能、可扩展和安全的系统
- 追踪和处理技术债，更早发现问题
- 能对上线的Bug负责，能看懂并处理AI写的Bug
- 或许以后的环节是，AI进行开发，软件工程师进行测试并进行修复
- 产品需求 -> 软件工程师写单子 -> 【AI编写 -> 简单功能 CICD测试 ；复杂/重要功能 由软件工程师 检查/修复（手工或AI修复）】-> 上线
- 或许以后的环节是，AI进行开发，软件工程师进行测试并进行修复
- 能编排智能体来干活
需要仔细审查生成的代码吗？看情况。 AI 生成的代码可能很啰嗦，或者重复造轮子而不是复用已有的抽象。但有些时候这完全可以接受，比如做概念验证，或者程序性能并不重要的场景。
测试和测试基础设施能力会更加重要。
AI 将在许多团队中写出 90% 以上的代码
坏消息是：变化可能会非常迅猛。 Claude Code 从 Boris Cherny 脑海中的一个想法诞生到现在，才刚刚一年多，类似的工具——OpenCode、Codex、Factory、Amp、Cursor，以及更多强大的智能体——就已经在改变软件的编写方式了。变化一直是科技行业的常态，但我不记得它曾经这么快过，也不记得它曾同时席卷整个行业！
还有一种失落感。 我正在慢慢接受这样一个大概率的现实：从今往后，我推上生产环境的代码，大部分都将由 AI 来编写。它已经写得比我快了，而且效果跟我自己敲出来的差不多。对于我不太熟悉的语言和框架，它甚至比我做得更好。
感觉有某种珍贵的东西正在被夺走，而且来得很突然。要把代码写好，需要花大量的功夫——学会编写能运行的代码、学会阅读和理解复杂代码、学会在代码出问题时调试和修复。我至今记得大学里第一堂“真正的”编程课（学 C 语言）让我多么望而生畏，记得第一份工作面对复杂代码库时那种迷茫无措，记得花了好几年通过实践、向其他开发者学习、读书、看> 博客才慢慢精进这门手艺。一旦你达到了相当高的水平，你就拥有了一种有价值且容易验证的能力——写出能跑的代码就是证明！
我关于构建软件的一些最美好的记忆，就是关于写代码的。进入心流状态，脑海里同时平衡着好几个想法，手指飞速地把它们敲出来，然后编译代码、运行代码，看到——"太好了"，一切按预期工作！
说实话，这种关系一直爱恨交织——写复杂代码需要的那种高度专注，本身就让人又爱又恨。然后还有时间估算引发的各种冲突：当你沉浸在一个难题中进入心流状态时，时间的流速是不一样的。
现在，这一切看起来都将成为过去。
我不禁想：从编写复杂代码的艰难中获得的那种成就感，未来还会有吗？是的，AI 很方便，但也有一种失去。
又或许，当 AI 智能体介入后，“进入心流”会转变为思考更高层次的问题，同时指挥 AI 去编写更复杂的代码？
不管怎样，地震级的巨变也意味着令人兴奋的新机遇。 我还从未在一场重大变革发生的当下就清醒地意识到它正在发生。这一次，我确信自己的编码方式将在 2026 年发生翻天覆地的变化，而由此产生的连锁反应将数不胜数。
13
中国在90年代就基本实现了婚恋自主，但到了21世纪，父母的介入似乎又在上
对于“如果对方符合您的择偶要求，但您还没有爱上他，您是否会和他结婚？”这个问题，2001年回答“会”的女性只有8%，而到了2023年已经上升到23.6%，男女都有超过两成的人明确表示他们会和不爱但符合标准的人结婚，远远高于2001年的数据。
2001年，只有6%左右的上海未婚青年对“谈恋爱和结婚是两回事”这个观点“非常同意”，但到了2023年，非常认同这个观点的比例已经上扬到了40%以上，女性更是达到了46.5%。
表单里面实际上可以看到，70%左右的青年都比较认同/非常认同 这个的观点
“对方父母通情达理、好相处”在理想结婚对象的10个条件中也排到了第三位，相当靠前。青年人开始主动认为，缔结婚姻关系是要和对方父母相处的，所以对方父母和自己合不合得来很重要。
中国亲子一体的文化和代际之间的无限责任，也深深压在青年人身上。他们一想到孩子的幸福终身都和自己挂钩，就感到很无力。
代际关系在中国既是一种支持，也是一种束缚。 对于中国人来说，只要孩子不结婚，他就一直是孩子，会一直照料他的日常生活。孩子没有钱的时候，只需要打一个电话，父母就会支援。因为孩子的任何风险，在父母看来，都是他们无法承担的风险。 因为有父母的保障，所以很多年轻人没有太大的动力，一定要建立自己的生活网络。很多年轻人会衡量，如果我的结婚对象跟我合在一起，不能让我过上更好的物质生活，我就没有必要往前迈这一步。男女都在做这样的计算。
代际关系给予支持的另一面，其实是一种隐性的掌控。特别是现在大城市的中产阶级父母的教育方式，和以前那种“不听话就打一顿”的方式很不一样，他们对孩子的亲密亲职，使得权威变得非常隐性。他们给孩子的自由，至少是包装出来的自由很多。比如想让孩子学钢琴，他们就带孩子去听音乐会，变成让他喜欢这件事。这种隐秘的爱的操控，也让孩子习惯了这样的状态，没有动力走出这个家庭。
另一个原生家庭的影响是，父母并没有提供一个好的婚姻模板。 那些迟迟不肯结婚，或者不能维持稳定的恋爱关系的青年人跟我讲述得最多的就是，他们在父母的婚姻中，看不到美好和幸福的影子。
在曾经普婚和早婚的年代，由于婚姻嫁娶的规范非常强大，人们还来不及处理原生家庭给自己造成的这些创伤，就走入了婚姻。但是到了晚婚和个体选择变多的时代，今天的青年人在进入婚姻前，必须诚实地面对和处理自己内心深处这些隐藏的伤痛。这个过程就必然造成年轻人在迈向结婚这个阶段时变得迟疑和犹豫。
四分之一人生危机
一个有趣的现象是，当这种无条件接纳的爱在婚恋关系中得不到的时候，青年人似乎把对这份爱的期待又转向了父母。
2023年在上海的调查数据显示，青年人对与父母关系的满意度比2001年显著下降。这是出乎我意料的，这个阶段父母对待孩子的态度、养育投入都在增加，都在变好，为什么子女的评价反而会降低呢？我的反思是，青年人的期待在变高。
现在大家对原生家庭的讨论那么多，也是因为大家对父母的期待非常高。很多人会把自己的问题放大地归责于父母，认为如果父母好一点，我就会好一点。这也是因为他们的社会关系太少了，能够投放情感和需求的地方好像只有家庭，只有父母。
在中国的社会转型中，家庭制度保持了强大的韧性，帮助个人度过了快速的社会转型、经济危机等等。但同时，工具支持、经济支持、情感支持和劳务支持，都压在了代际关系上，这其实也反映了青年人社会网络和社会发展空间的一种逼仄。
所以，作为时代症候的一种镜像，我认为“懒婚”在一定程度上反映了当下青年人发展的一种困境。
事实上，这种困境也是全球性的。社会学和心理学有一个概念叫“成年初显期”，这是阿尼特在2000年提出的，他发现进入21世纪以后，人的青春期和成年期之间出现了一个非常明确的过渡阶段。
那些经济发展越好、福利越高的国家，这个阶段也越长。有的是从20到25岁，有的是25岁到30岁，甚至是35岁。
这个漫长的过渡期最大的特征就是不稳定：职业身份不稳定、亲密关系不稳定、没有父母身份，它反映的是生理成熟与社会成熟之间的脱节和断裂，因此也造成了“四分之一人生危机”。
在这个阶段，青年人会出现焦虑、迷茫、不确定、孤独，甚至自我怀疑。
在中国的家庭主义传统之下，紧密的代际支持扮演了重要角色，极大缓解了社会转型过程中出现的青年贫困以及相关的社会问题。但与此同时，青年人也面临更严峻的“关系贫困”问题。
在我看来，更多是因为他们没有关照到青年人的生命体验。婚姻家庭制度的规范还停留在生存范式，对结婚生子、组建家庭的价值讨论也主要停留在传宗接代、后继有人、阶层流动和利益交换的工具性意义层面，没有出现一个让青年人能够接纳的新的婚姻家庭文化脚本。
我觉得中国的青年人也一样。当我们将自己的人生处境，放在更宏大的社会结构中去理解的时候，可能更有力量去行动，也可能找到更多的方向。只有青年人自身真正迈出脚步，才能探索出一种属于他们的新的婚姻文化脚本。
17
AI编程能力边界探索：基于 Claude Code 的 Spec Coding 项目实战｜得物技术
https://weread.qq.com/web/mp/reader/7dc420e224d505f5758535f333931353137383534342f2
案例四：复杂问题排障 中讲述了一个 复杂问题
最后确认的原因：
.npmrc 历史副作用：早期为跳过 @next/swc-darwin-arm64 在 Linux 下载而加入的 omit=optional，无意间也跳过了 @tailwindcss/oxide-linux-x64-gnu（Tailwind v4 的 native binding），postinstall 陷入循环等待
Prisma v6 境外下载沉默卡死：AI 需要阅读 node_modules/@prisma/fetch-engine/dist/index.js 第 2319 行才能发现这个行为——postinstall 不报错、不超时，只是无限等待。
pnpm 跨平台 lockfile 不一致：macOS arm64 生成的 lockfile 不含 Linux x64 的 native package；切回 npm 则 lockfile 被忽略，安装结果每次不同。
从最后确认原因来看这个 问题非常复杂，交给AI来解决实际上花了不少功夫
文章作者认为 这个问题难度 超出了 AI 通过训练数据或当前上下文主动推断的范围
我比较认同这个观点，相比于 AI 在代码生成领域的势如破竹，AI在解决复杂 实际问题时的表现 任然不尽如人意
为什么？
我认为 实际上 来说 开发页面本来就不是一个太难的活儿，对于一个前端工程师来说，常规的 中台开发 实际上和 厂里面拧螺丝差不多
只不过其中一些确实难度很高，需要脑子解决
就像是 AI 在代码中的这套叙事其实和 纺织机，工厂机器人 的逻辑别无二致
现在机械厂仍然需要人工解决一些复杂的问题，纺织行业 很多 复杂的织法也不是目前的机器能织出来的
不过类似的是，纺织机的能力在不断提升，AI也一样，实际上到后期，AI生成的占比会相对稳定到某一个比例，然后 软件研发的流程会卡在其他阶段
比如沟通，上下游等等
此外，我看到了 他们用了3层多个约束文件来规范AI生成代码的规范
第一层：约束层（.claude/rules/） ← 告诉 AI「禁止什么、必须怎样」
第二层：示范层（.claude/code-design/）← 告诉 AI「标准产出长什么样」
第三层：视觉层（.claude/ui-design/） ← 告诉 AI「页面应该长什么样」
.claude/rules/
├── ts.md # TypeScript 规范（禁止 any、使用可选链等）
├── code-names.md # 命名规范（kebab-case/camelCase/PascalCase）
├── comment.md # 注释规范（JSDoc、@ai-context/@ai-rules 文件头）
├── lint.md # 代码风格（单引号、文件末尾换行）
├── style.md # 样式规范（Tailwind CSS、less 文件）
├── pages.md # 页面目录结构规范（constants/services/hooks/components 分层）
└── service.md # API 接口生成规范（fetch{Name}Api 命名、UniversalResp 泛型）
.claude/code-design/
├── pro-table/ # 通用列表页模板（含搜索、分页、批量操作、行操作）
├── pro-form/ # 通用表单页模板（含创建/编辑双模式、字段验证）
├── editable-pro-table/ # 可编辑表格模板（含行内编辑、添加/保存/删除）
├── drawer/ # 抽屉组件模板（含标准打开/关闭逻辑）
├── compontent/ # 通用组件模板（含 README、Props 定义、使用示例）
└── utils/ # 工具函数模板
.claude/ui-design/
├── knowledge-spaces.html # 知识空间列表页设计稿
├── search-strategy.html # 检索配置页设计稿
├── space-detail.html # 空间详情页设计稿
└── xxx设计稿第一次觉得，这种复杂约束或许确实有比较好的效果
流行的说法是「AI 是你的 Copilot」。这个比喻在日常补全层面成立，但在 Spec Coding 实践之后，我更倾向于另一个模型：AI 是一个极度服从、无限耐心、但没有内部业务知识常识的「顶级执行者 」。
极度服从：AI 会一字不差地执行你写的规范，不会主动质疑「这样做合理吗」。这是优势，也是风险——规范写得越准确，执行越可靠；规范有歧义，AI 会选一个「看起来合理」的解释，而不是停下来问你。
如何根据需求选咋 不同级别的 更新，有些小的修改 比如这个改成 true，这种，建议上下文越少越好，对于稍微复杂一点的，需要 rule/spec 来约束
任务涉及的领域没有规范约束，AI 自行填充「合理默认值」。
规范设计能力成为 AI 时代开发者的核心竞争力——能写出让 AI 可靠执行的规范，价值比能写出同等功能代码更高。
系统性思维变得更重要——生产构建问题的排障经历说明，AI 可以帮你解决每一个局部问题，但无法帮你看到真实业务全局。
质量意识前移——过去 Code Review 在代码写完后进行，现在需要在 方案设计/任务执行 阶段就介入，而不是等 AI 执行完再纠错。
规范体系的结构化积累：每次踩坑后补充到 CLAUDE.md/rules，形成团队共享的「AI 执行约束库」。目前 7 条规范文件是手动维护的，下一步可以建立「踩坑→提炼规范→自动追加」的闭环。
MCP 工具链的纵向延伸：本项目 MCP 仅覆盖了接口文档、飞书文档。后续针对设计稿、测试用例、发布平台、日志平台接入，可以进一步形成完整的AI Coding链路。
多 Agent 并行开发：本项目开发过程中，发现大型任务执行等待时间较长，下一步可以尝试多Agen并发生成，同时开发不同功能模块。
18
我们分析了 Kilo Code Reviewer 在实际编码任务中的成本
https://blog.kilo.ai/p/we-analyzed-how-much-kilo-code-reviewer
省流：在小提交中使用便宜的比如 kimi模型进行 code review，在大型分支合并时使用更好更贵的模型进行code review
另类炒股法：A股“日历效应”
https://vipmoney.eastmoney.com/CommonArticle/DetailShare/177?from=singlemessage
- 周四价格偏低，资金普遍流出
- 操作：周四空仓
- 11月到次年5月份 一般来说上涨概率大，6-10月份 下降概率大
- 操作：在5月份卖出 6-10月份保持空仓
- 大假期（元旦、春节、10.1、5.1）放假后会涨
- 操作：节前6个交易日买入，节后6个交易日卖出
- 2会之后 会上涨约 5%
- 美国总统换届后期间A股上涨