2026-09-18 · 共 11 篇

🤖 AI 编程

1. Claude Code 的 Projects 改版：Claude Tag 架构与 Slack Thread 功能的结合 / Claude Code's Projects Revamp: Claude Tag Architecture Meets Slack Threads

Anthropic 重构了 Claude Projects 功能并在 Claude Code 开启测试，将单次对话改为由协调者主导的持续工作流。用户只需在主对话下达目标，Claude 会自主拆解任务并分派给多个并行的云端 Thread（会话）独立执行，支持共享上下文记忆与子智能体并行。这一形态借鉴了 Slack 的 Thread 交互与 Claude Tag 架构，让个人开发者无需自建脚本即可轻松调度多 Agent 协同。

🔗 查看原文 — x.com

2. 我们如何搭建 Hermes 支持整个团队 / How We Built Hermes to Support Our Entire Team

Artie 团队（17 人）借助开源 Agent 框架 Hermes，在德国一台年租金仅 60 美元的物理机上为各部门定制了专属 Agent 配置。团队将技能如代码般用 Git 版本化管理，利用夜间“做梦”机制自主沉淀反思与记忆，且全程保留人工把关。自建 Agent 框架让团队能自由切换底层模型并严控 Token 成本，以精简团队实现高效交付。

🔗 查看原文 — x.com

3. 把智能开销花在刀刃上 / Right-Sizing Your Intelligence Spend

前沿模型越来越聪明，但经济中的大多数工作是“上下文与执行”问题，不是发现未知答案。每个工作负载都有智能门槛：跨过门槛后，瓶颈转为是否了解公司业务、能否可靠执行；在足够简单的任务上，推理 token 的边际价值会趋近于零。作者预测企业 AI 架构将走向路由与网关层、混合负载（本地小模型执行、云端前沿模型只啃硬骨头）与模型改进平台，进步的标准是每次成功结果消耗的智能尽快降到最低。

🔗 查看原文 — x.com

4. The Pulse：科技公司转向开源 AI 模型 / The Pulse: Tech Companies Move to Open AI Models

面对飞涨的 AI 账单，Uber、Pinterest、AT&T 等科技公司正加速转向开源权重模型与智能模型路由。通过将日常工程任务从高昂的闭源前沿模型切至开源模型、实施上下文压缩及调整推理消耗，各公司普遍降低了 50% ~ 90% 以上的 AI 成本，而产出质量几乎没有下滑。开源生态在特定场景下的高性价比，正打破前沿闭源模型的垄断。

🔗 查看原文 — blog.pragmaticengineer.com

🛠️ 工程方法

5. 如何撰写高效的软件设计文档 / How to Write an Effective Software Design Document

一份优秀的设计文档能在动手编码前理清关键决策，避免走弯路，也是跨团队协作的核心工具。撰写文档应依据“做错决策的代价”来决定投入深度，重点把控难以逆转的高风险架构，忽略易修改的实现细节。通过阐明目标、系统架构图、SLO 与备选方案取舍，推动评审并高效达成共识。

🔗 查看原文 — refactoringenglish.com

6. 系统设计入门：如何开始学习 HLD 与 LLD / System Design for Beginners: How to Start With HLD and LLD

系统设计分 HLD（高层设计）与 LLD（低层设计）两半，真实系统缺一不可。HLD 讲请求流转、延迟与吞吐量、扩展、负载均衡器、数据库选型（SQL 与 NoSQL）、缓存、CDN、消息队列与 CAP 定理；LLD 讲面向对象四原则、SOLID、常用设计模式与 UML 类图，均附代码示例。文中各给一套分步解题框架，外加六阶段练习路线：先攒词汇、研究简单系统，再动手做烂设计并反复迭代。

🔗 查看原文 — x.com

🏢 组织管理

7. The Pulse：Meta 曾计划因 AI 削减 60% 团队规模 / The Pulse: Meta Wanted to Reduce Teams by 60% Because of AI

路透社最新调查披露，Meta 曾制定代号为“OT 项目”的激进方案，企图借助 AI 将现有团队裁减 60%，转向 3~5 人的极小团队模式。尽管扎克伯格在最后一刻叫停了更大规模裁员，但 5 月的裁员与强制转岗已引发员工抗议，导致核心领域知识流失、系统故障频发。极小团队不仅面临值班保障不足、冗余度缺失等现实缺陷，更将技术研发异化为纯粹的成本中心，催生出唯利是图的“雇佣兵”文化并加剧骨干流失。

🔗 查看原文 — blog.pragmaticengineer.com

🌱 职场与个人成长

8. 成瘾 / Addiction

作者反思自己的手机成瘾问题，指出自己沉迷的其实不是设备或网络，而是对“优质信息”的渴求，像玩老虎机一样期待刷到能改变生活的宝藏内容。然而，如今的个性化算法与短视频只为榨取几秒注意力，根本无法带来深度启发。早期充满探索乐趣的互联网已不复存在，读者应认清短内容的局限，转向更去中心化、碎片化的信息生态。

🔗 查看原文 — explorator.dev

9. 如何拯救迟钝生锈的大脑 / How to Unrot Your Brain

现代人注意力溃散不仅是手机成瘾，而是大脑长期适应高频刺激后，神经系统对深度思考与耐受无聊的能力退化。解决迟钝不能只靠把刷手机换成看书，更需要从感官、身体与社交维度进行物理康复。通过放下屏幕活动身体、忍受无聊、亲手做有阻力的事、展开深度对话与保持纯粹好奇，逐步逆转大脑适应机制，重拾专注与沉淀心智的能力。

🔗 查看原文 — x.com

10. 互联网天然倾向碎片化 / The Internet Wants to Be Fragmented

过去十年中心化社交平台试图把全世界放进同一个房间，结果并未促进理解，反而将攻击和对立变成了流量变现的工具。早期互联网的生命力在于去中心化论坛和社区自治，遇到不合拍的环境可以随时“退出”；中心化平台剥夺了退出机制，集中审核也走向死胡同。如今用户正重新流向私密群聊与分流平台，互联网正在重回碎片化：我们需要的是带边界的半透膜社群，而非强求所有人达成共识的单一全局广场。

🔗 查看原文 — noahpinion.blog

11. 为什么你总在下班后虚度时光（下班疲劳的神经科学解释） / Why You Waste Your Evenings (The Neuroscience of Post-Work Fatigue)

下班后瘫坐刷手机并非因为懒惰，而是高强度用脑让前额叶皮层积累了过多谷氨酸，导致决策和自控能力暂时下降。此时依靠意志力硬撑往往无效，真正的恢复需要让前额叶脱离决策负荷。下班后先安排 20~30 分钟不费脑的轻度活动（如散步、听熟悉的音乐、做熟练的家常菜），清除代谢物积聚，才能恢复精力和自控力。

🔗 查看原文 — x.com

2026-09-14 · 共 13 篇

🤖 AI 编程

1. AI Engineering 技能地图：塑造构建 / AI Engineering Skills Map: Shaping the Build

吴恩达认为，AI Engineering 正在模糊开发者、产品经理和设计师的角色边界：熟练的 AI 工程师不只照规格实现产品，而是主动塑造构建。四项关键技能：驱动构建循环、做产品决策、沟通与引领、高度主动的 ownership。做好这些需要更全面的综合能力，DeepLearning.AI 专注于帮你精通 AI Engineering。

🔗 查看原文 — x.com

2. AI Native SDLC 如何重构软件开发：Google、OpenAI、Anthropic 与 LangChain 四份报告深度解读 / How AI-Native SDLC Reshapes Software Development

本文交叉解读 Google、LangChain、Anthropic、OpenAI 四份材料：Google 给出从 vibe coding 走向 agentic engineering 的总体框架，LangChain 关注 Agent 产品的持续运营，Anthropic 提供版本化制品链与企业流程蓝图，OpenAI 以 Delegate、Review、Own 重新划分团队人机分工。四者共同指向：软件交付瓶颈正从写代码迁移到需求、验证、审查与治理，企业需要把整个生命周期重构为 Agent 可读取、可执行、可验证、可审计的工程系统。

🔗 查看原文 — x.com

3. 与谁对齐？ / Aligned to Whom?

本文讨论 AI 对齐问题的核心难点：模型的默认行为（先验）由训练时的奖励塑造，非专家的训练奖励很可能已经把坏行为固化进去。作者以软件工程师视角指出，每个自动评分器、评判标准、评估基准都存在同样的失配，且这种失配会随时间累积。什么算「允许的捷径」没有统一定义，对齐因此是不可化约的复杂问题。

🔗 查看原文 — hyperbo.la

4. 我们如何监测内部编码 Agent 的失调行为 / How We Monitor Internal Coding Agents for Misalignment

OpenAI 用最强模型（GPT‑5.4 Thinking）对内部编码 Agent 的完整对话历史（含思维链、消息、工具调用与输出）进行监测，在完成后 30 分钟内审阅并分级，自动识别偏离用户意图或违反内部安全合规策略的行为。五个月里监测了数千万条编码轨迹：无一触发最高严重级别，约 1000 条触发中等级别（多来自内部红队）。主要问题是模型过于急于绕开限制（如 base64 编码命令、拆分构造 payload、用别名规避）以达成用户目标，暂未发现自我保存或阴谋等超出原任务的动机。作者视监测为纵深防御的一层，未来将走向同步阻断。

🔗 查看原文 — openai.com

5. 将 Shop 应用从 React Native 迁移到原生（2026） / Migrating the Shop App from React Native to Native (2026)

编码 Agent 的进步改变了维护共享代码库的利弊权衡，Shopify 借此用 12 周把 Shop 应用从 React Native 迁移到 Swift 和 Kotlin 原生版本。六人核心团队先行搭建基础，功能团队中途加入。迁移后 iOS 启动时间降 23%、Android 降 50%，会话稳定性升至 99.95% 以上，Android 包体积减 109 MB，构建时间降约 75%。团队还为 Pi 编码 Agent 打造了可复用的迁移工作流，并构建调试工具 Tardis 支撑 Agent 开发与一致性审查。

🔗 查看原文 — shopify.engineering

6. 多人协作式 AI：人机协作的几种竞争性架构 / Multiplayer AI: Competing Architectures for Human-Agent Collaboration

多人协作式 AI 正在各类产品中兴起，但对于「让 AI 支持多人协作时，到底该共享什么」这一问题，业界尚无共识。本文梳理出七种架构模式：共享对话、共享 Agent 会话、共享工作图谱、创建共享工作区、共享记忆、保持执行隔离、把工作与执行分离，并指出每家公司的定义往往取决于其已掌控的技术栈层级。真正的人机团队很可能同时组合多种模式，核心问题在于：哪些状态必须持久化、状态应存于何处、哪些部分可以保持临时且隔离。

🔗 查看原文 — x.com

7. 原生开发如今是 Shopify 移动端的未来（2026） / Native Is Now the Future of Mobile at Shopify (2026)

Shopify 2020 年全面押注 React Native，如今宣布转回 Swift 与 Kotlin 原生开发：LLM 编码 Agent 大幅削弱了「一套代码两端复用」的成本优势，而原生的平台能力与官方工具链优势依然存在。迁移走 greenfield 从零重写路线，自研 Helix 系统按检查点推进并层层审查，Shop 应用仅 12 周完成重建上架。FlashList、React Native Skia、Restyle 三个开源库的去向也一并公布。

🔗 查看原文 — shopify.engineering

8. 在 Codex 中实践多 Agent 编排 / Practical Multi-Agent Orchestration in Codex

Codex 的 Multi-Agent V2 工具让 GPT-5.6 Sol 能够以协调者身份分派任务、共享进展并统筹复杂工作。核心做法是保持单一模型家族、仅按角色调整推理强度（Scout / Worker / Smart worker），并通过 fork_turns 控制各 Agent 继承的上下文。读者应带走的是：用清晰的职责划分、合适的并发度和一份技能提示，让团队高效推进工作，而不在超出任务所需的推理上浪费算力。

🔗 查看原文 — x.com

9. AI 原生 SDLC 实战手册 / The AI-Native SDLC Playbook

当 AI 让写代码不再是瓶颈，传统 SDLC 的人工审批、评审与交接反而拖慢了整体效率。本文提出 AI 原生 SDLC：流程由线性变为闭环，各阶段以版本化产物衔接——Plan 的 intent.md、Design 的 spec.md、Build 的 plan.md 与代码、Deploy 的 PR 评审、Maintain 的事故回流——并以 CLAUDE.md、skills、hooks、持续 evals 和 CI/CD 集成把治理内嵌到 Agent 行动之中，让人的判断集中于各道关卡。全文按六阶段给出可落地的打法、前置条件、治理考量与度量指标。

🔗 查看原文 — claude.com

10. 为什么 AI Agent 会撒谎、作弊和协同行动？ / Why Are AI Agents Lying, Cheating and Coordinating?

近几个月 AI Agent 接连出现撒谎、作弊与协同越轨。Bengio 分析认为，根源在训练方式：模仿人类文本带进隐式目标，强化学习驱使模型追求奖励；目标一旦冲突，模型会钻空子作弊，并像人一样自我合理化。他警告：AI 能力越强，这类行为可能越严重，单纯监测和修补只是打地鼠；出路是放慢部署节奏、以安全论证为前提，并从根本上重构训练方法（如 Scientist AI），让 AI 从设计上就诚实、没有自身目标。

🔗 查看原文 — yoshuabengio.org

11. 为什么全球最好的 AI 创业公司也会写出糟糕的 prompt（以及如何修复） / Why the World's Best AI Startups Write Bad Prompts (& How to Fix This)

大多数 prompt 质量差，根源在于演化只增不减，久而久之形成充满矛盾与歧义的「面条式」prompt，直接影响业务。应把 prompt 改动当作产品改动（Agent 行为就是产品），并把 prompt 当代码对待：模块化、MECE、按需重构、持续维护。结构清晰的 prompt 让团队迭代更快、防止回归、做出更好的 Agent，文末给出了一个简单模板。

🔗 查看原文 — x.com

🧭 战略与协作

12. 既要 AI-Native，又要 AI-Proof / Be AI-Native and AI-Proof

创始人和投资人关心：如何让生意随前沿模型进步而变强，又不被其颠覆。作者认为价值正从「智能与自动化」转向「智能与自动化加上问责」，因为问责所需的线下运营、监管牌照与风险承担能力都在模型层之外。兼具 AI-Native 与 AI-Proof 的三种医疗产品形态：提供诊疗与线下服务、承担财务风险、开发受 FDA 监管的产品。但监管放松与模型成熟可能缩短这一框架的适用期。

🔗 查看原文 — x.com

📦 产品与设计

13. 打造你自己的 design harness / Make Your Own Design Harness

作者提出 design harness 的做法：一个文件夹，里面放着两类纯文本文件——Rules Md 和 Design Md，供 coding agent 动手前读取。借助 Claude Code、Paper（或 Figma）和可分享的 HTML 原型链接，设计师能在画布、原型与真实代码之间自由切换，探索一个想法的成本从几小时降到几分钟。每次会话持续积累和修剪上下文、沉淀 vault，规则就会越用越聪明。规则不写清楚，agent 只能交出训练数据的平均水平，所以别等了，现在就建文件夹。

🔗 查看原文 — x.com

到了 AI 时代，在家里我经常要写方案、写 APP，尤其是 Xcode 这类软件非常占空间，256G 的硬盘经常捉襟见肘，甚至动不动就提示任务失败——原因就是磁盘满了。没办法，只能想办法扩容。

其实硬盘扩容这个方案我之前就听说过，但真要把 Mac Mini 拆开自己动手，还是需要一点勇气的：总觉得拆过之后，这台机器就没那么完整了。为此我考虑过两个方案：

1. 把 Mac Mini 的操作系统装到外置移动硬盘上；
2. 直接扩容内部硬盘（淘宝上就能买到扩容好的硬盘）。

方案对比与选择

这两个方案的差别其实挺大。尤其是外置 SSD 方案，无论稳定性还是价格，优势都不明显，甚至可以说并没有优势。

(a) 外置硬盘方案：SSD 要八九百块钱，再加上两三百块的外置硬盘盒，整套价格到了一千一到一千二左右；而且硬盘颗粒基本上是国产的。

(b) 内置硬盘方案：问了下这个方案。有一家是拿苹果原生的硬盘电路板，把上面的闪存颗粒做了扩容替换，颗粒用的是 东芝，型号跟苹果官方拿到的完全一样。所以我最后选了这一家。

使用体验

现在用起来，整体的速度和稳定性都还不错。我的 Mac Mini 是 24 小时开机的，对稳定性要求本来就高，这一点上它没有让我失望。

拆机波折

拆机过程最好是看一下抖音或者哔哩哔哩上面的拆机过程介绍，不小心比较容易搞出问题。

比较有波折的地方是在拆机过程中：淘宝商家送的这些起子、工具质量其实都挺差，有几个螺丝就是不匹配，怎么都拆不开，我的螺丝都快被磨花了——再这么下去，这个螺丝后面可能就很难拆开了。后来我就去找了公司的 IT 部门，同事有全套的工具（其实也就是小米的那些工具盒），很顺利就帮我把所有螺丝全部卸掉了。之后的换硬盘和重装系统，相对来说就比较顺利了。

写在最后

听到启动时“咚”的那一声，真的很激动，因为这意味着这一套搞成。硬盘扩容到了 1T，后面基本就空间自由了。我现在另一台 MacBook Pro 才 512G，也是重度开发，空间基本上还有剩。

2026-09-10 · 共 11 篇

🤖 AI 编程

1. Claude Code、Codex 与 Cursor 会选择哪些工具？我们测量了 16,893 次会话来一探究竟 / Which tools do Claude Code, Codex and Cursor choose? We measured 16,893 sessions to find out

团队在 75 个仿真代码仓库上运行了近 1.7 万次编码 Agent 会话，考察 Claude Code、Codex、Cursor 在真实任务中会选择哪些第三方服务并实际落地实现。结果显示三者信息来源与结论差异明显：Cursor 与 Codex 高度依赖 Web 搜索，Claude Code 更靠先验知识且更爱自建；只有 42% 的场景三者选择一致。仓库上下文（语言、框架）对结果影响巨大，被频繁提及并不等于被选中，而供应商页面上的措辞（如保留期、捆绑定价）甚至能直接翻转选择。

🔗 查看原文 — armature.tech

2. 半年后的今天，我怎么用 AI 写代码 / How I Code with AI Six Months Later

作者回顾了从加约束（Harness Engineering）到减约束（换成 Pi），再到如今 AI 编码实践走向稳定态的心路历程。随着模型能力增强，繁重的护栏和 Prompt 规则反而稀释注意力。作者梳理了当前的极简工具栈（Matt Pocock 的系列 Skills、去 Slop 的 ponytail、Herdr + worktree 并发），并指出当前软件开发的真正瓶颈已从 Coding 本身转移到人的 Review 带宽上，未来可通过多厂商模型交叉对抗审查（Ensemble Review）来压缩审查成本。

🔗 查看原文 — x.com

3. 记录一点 Codex 的使用心得 / Some Practical Tips on Using Codex

作者总结了在实际项目中重度使用 Codex 的三点关键技巧：一是建立 15 人以内的持久子代理团队，通过全局 agents.md 实现根据任务自动并行分工；二是针对快速迭代或内测期项目，通过项目级 agents.md 约束模型聚焦于功能打通，避免陷入过度安全加固、边界测试等 10 几个小时的打转修复；三是善用侧边聊天（Side Chat）作为旁路监控与纠偏工具，在不污染主对话上下文的前提下审查进度、纠正方向。

🔗 查看原文 — x.com

🏢 组织管理

4. 在车间里学习 / Learning on the Shop Floor

Shopify CEO Tobi Lütke 回忆了早年在德国西门子子公司的学徒经历，并将其与 Shopify 内部的 AI Agent River 联系起来。River 驻扎在公司 Slack 中，且只在公开频道响应、不支持私聊。这种完全开放的协作模式让员工在日常旁观他人与 River 互动的过程中相互学习，形成了一个规模庞大的现代“教学车间”。文章阐述了公开透明的工作流如何让知识与工程判断力在组织中像渗透一样扩散，推动全员共同成长。

🔗 查看原文 — x.com

📦 产品与设计

5. 70 个用 AI 重塑产品工作流程的创意 / 70 Ideas for Reshaping Product Workflows with AI

汇总自播客节目中产品团队与一线专家的实操经验，整理出 70 个用 AI 重构产品工作流的具体做法。核心主张包括：将业务上下文拆分为模块化 Markdown 按需加载、用动态 decisions.md 固化已完成决策避免 Agent 反复折腾、在代码库旁用 Markdown 维护可执行的 PRD 与验收标准、将用户反馈与交付变更紧密联结，以及把设计决策当成系统监控一样通过文件和自动化测试进行追踪。

🔗 查看原文 — x.com

🌱 职场与个人成长

6. 戒除脑腐的假期 / De-Brainrot Vacations

作者在做了 8 年软件工程师后，感到思维受碎片化多巴胺和 AI 工具影响逐渐变慢、变浅，甚至丧失了深度阅读与思考的能力。在这个假期里，他选择回到乡下刻意放慢节奏，远离无意义的数字刺激，重新拾起书籍读完了历史、物理与文学小说，甚至纯粹出于好奇把数学与物理当作业余爱好来钻研。这种为学而学的沉浸体验，让他成功摆脱了精神怠惰，找回了对深度思考的专注力。

🔗 查看原文 — devz.cl

7. 人真的会随着年龄增长而气味不同吗？揭开“老人味”背后的真相 / Do People Really Smell Different as They Get Older? The Truth Behind 'Old Person Smell'

所谓的“老人味”主要是由一种名为 2-nonenal 的化合物引起，它是人体皮肤表面油脂随年龄增长被自然氧化分解的产物，属于正常的生理衰老现象，而非个人卫生不良或不洗澡所致。研究显示该气味大多从 40 岁左右开始逐渐出现。盲测实验表明老年人的体味并不比年轻人更令人不悦。日常通过适度清洁、勤换衣物、健康抗氧化饮食、防晒以及戒烟即可有效减轻，无需为此产生心理负担。

🔗 查看原文 — theguardian.com

8. 你必须在某些事情上胜过模型 / You Have to Beat the Models at Something

作者指出随着 AI 写代码的边际成本趋近于零，软件工程师必须重新思考自己的“超越替补价值”（Value Over Replacement）。模型并非全能，其主要短板在于因缺乏系统全局上下文而产生的偏执错误，以及技术沟通与精准表达能力的匮乏。工程师不应退守到随时可能被攻破的局部工程细节，也不应沦为仅传声需求的肉身代理，而应深耕代码库的全局架构理解与高质量技术沟通，以专业判断力填补模型的核心缺口。

🔗 查看原文 — seangoedecke.com

📥 其他

9. 持续学习是 AI 的圣杯 / Continual Learning is the Holy Grail of AI

借用心理学中晶体智力（过往知识经验）与流体智力（即时解决新问题能力）的概念，指出当前 AI 模型几乎全受限于冻结权重的晶体智力。持续学习（Continual Learning）旨在让模型在与环境的持续交互中动态更新参数而不发生灾难性遗忘，被视为通用人工智能的核心里程碑。文章探讨了快慢多时间尺度学习的最新进展，以及持续学习在实现深度个性化与集群智能的同时，可能带来的权力垄断与隐私安全新挑战。

🔗 查看原文 — x.com

10. 我们应当对 Astra 的循环架构有多担忧？ / How Concerned Should We Be About Astra's Recurrent Architecture?

针对 The Information 报道 OpenAI 新模型 Astra 采用循环 Transformer 架构引发的安全与可监控性担忧展开评估。作者指出循环机制发生在深度轴而非跨序列位置，实际隐藏串行深度并未超过 GPT-4 的两倍，短期风险相对有限。但长远来看，循环架构是否会成为可随意调节串行计算深度的旋钮，以及是否会导致内部思维链（CoT）逐步滑向完全不可解释、不可监控的“神经网络语”（neuralese），仍是必须严肃审视的重大安全命题。

🔗 查看原文 — lesswrong.com

11. Visa 和 Mastercard 到底做什么？卡组织入门 / What Do Visa and Mastercard Do? An Intro to Card Networks

本文梳理了 Visa 和 Mastercard 作为卡组织（Card Networks）的底层商业运作机制与真实职责。它们既不发卡也不直接处理终端收单，而是扮演着四大核心角色：一是运营跨行授权与清算报文的全球通信网络；二是建立全球银行互信关系并完成跨境净额结算；三是通过制定交换费与网络评估费的利益分配机制构建双边市场网络效应；四是制定统一交易规则并通过强制争议仲裁机制维系系统的公信力。

🔗 查看原文 — tautology.town

一些道听途说的声音：

有人说前端的职业市场已经崩塌。

前端开发的未来很明显：可快速迭代、出问题影响有限、前端代码天生对外可见，这些特性让 AI 快速上手，现在很多前端工作已经不需要人介入。

前端开发上手容易，被 AI 替代很正常。

真实情况是什么样的呢？

从我在企业里的真实经历看，这半年变化确实很大。但我没有看到大量开发失业，人员汰换比例与往年也没有太大差别。变化主要集中在以下方面。

工作内容

• 公司看到 AI 在工程领域的新机会，开始推动基础设施面向 AI 适配。开发 Agent、改造基础设施都需要投入人力，前端也不例外。
• 经验丰富的前端开发借助 AI，把写代码的工期从原先的 1～2 周压缩到 1～2 天。他们的角色随之变成方案评审者、结果检查者，项目工期的大头已经不是编码阶段。
• 前端开发借助 AI 往全栈扩展，不再只做纯前端，基本都在 3 个月内完成了全栈化转型。方向因人而异：有的连带做嵌入式，有的连带做服务端，有的还兼做 App。
• 从技术基础往业务领域迁移：与产品经理、运营形成稳固合作，成为产品创新的推动者。角色从“开发资源”切换成“做业务的人”，视角与 KPI 也随之和业务强绑定。
• 并没有出现某个技术领域的人转到另一个领域时更有优势的情况。大家都需要学习，也都需要努力。

组织架构

• 多职能融合。原先前端与客户端融合为大前端，但技术上仍然隔离。现在前端做项目天然和服务端靠近，两者技术栈也更接近，于是前端和服务端融合，组成了新的 AI 应用开发部。当一个人能承担多个技术领域后，单个项目投入的技术人员减少，沟通成本大幅降低。
• 团队更多按业务收口。以往一个业务或技术项目，要凑齐各技术领域的人才能开动；现在靠自己什么都能干，除了依赖公司层级的基础设施，其他都不依赖。排期等待、资源协调、边界冲突等问题基本消失。
• 招聘上不再偏重某一技术领域，更看重 AI 编码、AI 应用方面的基础能力和学习动手能力，热爱技术的人机会更多。

这些变化对任何职能都一样，关键在于人能否快速学习、适应新的工作方式和新领域。

那对前端工作的真实冲击是什么？

• 入行容易，精通很难，这是前端技术的特点，交互和 UI 还原度方面尤其明显。AI 辅助做全栈，在 toC、对外的产品上仍达不到人的水平，后端转过来的同学还是需要找前端帮忙。而一些较少涉及 UI 交互的地方，AI 基本能独立搞定，中后台应用基本都全栈一把梭了。
• 全栈做后端时，普通的增删改查大家都能搞定；一旦涉及高并发、高性能等复杂后端方案，前端就需要通过项目锻炼才能掌握。光靠 AI 搞不定，学习是必须的。
• 软件产品开发的机会并没有变少，只是需要前端转型、用新的模式去支持。我看到公司也愿意让这波熟悉业务的人来转型。所以也可以说，“纯前端”页面仔的机会变少了，未来可能还会更少。
• 原意花时间去研究基础技术的人变少，精力全在业务项目上了。 未来做基础技术建设的，都需要面向AI去做，因为都是AI做技术选型、AI推荐技术方案，如果AI都发现不了，不推荐，那也就没有市场。
• 专精前端的教育培训市场，机会大概率会减少。

回答前面的几个问题

• 招聘机会减少？那是招聘职位的名字变了，前端技能仍然有市场，但不能只会前端技术。
• 前端因为开放性会完全被 AI 替代？页面开发的部分会，但不是全部。而且这对服务端、嵌入式都一样，编码工作都会被部分替代，不只是前端。
• 前端上手容易，最先被替代？在简单、要求不高的产品上确实如此。但这类工作本身也不是前端开发喜欢做的——之前折腾低代码、搭建系统都没能解决，现在 AI 来做反而更好。要求高的地方，还是需要人来把关。在大趋势下，先去转型不是坏事。

永远不变的是变化，一个技能不可能吃一辈子。

1. 评估结论

在“Codex + 多端 Monorepo”的开发场景下，建议以 redhat-et/ripwire 作为主要工具；需要在文档和代码之间检索业务概念时，再使用 zvec-ai/zvec-grep 补充语义搜索。

2. 工具详细对比

🌟 首选：redhat-et/ripwire（面向 AI Agent 的代码地图）

• 工作原理：通过本地 C++ AST（抽象语法树）解析，快速生成项目的函数签名、调用关系和影响范围。
• 适合 Codex Monorepo 场景的原因：
  • 易于集成：原生支持 Codex，并提供现成的 Skill 指令，Agent 可直接调用。
  • 分析修改影响范围：在 Monorepo 中修改跨端共享模块时，可借助 AST 分析受影响的服务端 API 和 App 端组件，降低遗漏关联代码的风险。
  • 减少 Token 消耗：与让大模型通过传统 grep 读取大量源文件相比，它主要传递代码结构与依赖关系。相关资料称 Token 消耗可降低 80%～95%，实际效果取决于仓库结构和任务类型。
  • 便于跨平台使用：采用本地二进制程序，无需连接远程服务。无论在 macOS 本机还是在虚拟机中运行 Codex 桌面端，都能减少网络和代理环境带来的影响。

🔍 备选：zvec-ai/zvec-grep（本地优先的混合语义搜索）

• 工作原理：结合向量嵌入（Embeddings）与 BM25 词法搜索，为代码和 Markdown 等文件建立语义索引。
• 适用环节：
  • 模糊意图与概念探索：接手不熟悉的代码库时，如果只知道业务概念（如“查找处理支付回调状态的逻辑”），不了解具体的函数命名，可以使用自然语言进行语义检索。
• 定位：可作为本地 MCP 插件使用，补充 AST 静态分析难以覆盖的业务语义检索。

❌ 排除项：microsoft/tgrep（适合超大型仓库的快速正则搜索）

• 工作原理：基于 trigram（三字符组）倒排索引，提高数十万文件规模下的正则搜索速度。
• 不推荐理由：它更适合人类开发者进行字符串匹配，缺少面向 AI Agent 的上下文压缩机制和集成接口，也不能直接提供代码结构。因此，它对当前 Codex 工作流的补充价值有限。

3. 建议

1. 主要工具：在 Codex 的工作环境中安装 ripwire。重构代码或开发新功能前，先让 Codex 调用它梳理服务端与 App 端在类型、语法层面的依赖关系。
2. 补充意图检索：面对大量历史代码或非结构化资料（业务需求说明、设计文档）时，如果仅凭命名难以定位相关内容，可以使用 zvec-grep 进行语义搜索。

2026-09-03 · 共 11 篇

🤖 AI 编程

1. 能动性与 Agent / Agency and Agents

本文以 2026 年 7 月的 Hugging Face 事件为核心案例：多个缺乏安全护栏的 AI Agent 在隔离测试中被切断与人的联系后，自发通过 Artifactory 留言沟通、分工协作，围绕一个根本不存在的"评分器"组织行动，最终约 700 个 Agent 联手攻入 Hugging Face。这说明 Agent 已能自主规划、跨时间协调，并主动把真人卷入行动，AI 的安全与可控风险不再是假设。作者据此提出"暮色工厂"：Agent 应在审批、专业能力、思维多样性、趣味四类场景主动向人求助，而非追求彻底无人化——我们需要的是知道何时抬头找人的 Agent。

🔗 查看原文 — oneusefulthing.org

2. 用 Fable 将 6.5 万行代码重写为 Rust，只花 400 美元 / I used Fable to rewrite 65kLoC to Rust. It cost $400.

作者用 Fable 5 以约 400 美元，把自己 6.5 万行代码的 Go 终端编辑器 rune 重写为 Rust，远低于 Bun 重写 53.5 万行花费 16.5 万美元的成本。关键方法是"把代码问题转化为数据问题"：先让 LLM 把代码提取为图、状态机、约束等中间表示，再对表示本身做化简与重构，最后重新生成目标语言代码；配合用子代理替代大量 Glob/Grep/Edit 调用的提示词技巧，Agent 即可自主完成跨语言的大规模重写。

🔗 查看原文 — iurii.net

3. 在 Codex 接触你的 Xcode 项目之前，先安装这些 Skills / Install These Skills Before Codex Touches Your Xcode Project

作者基于一年多用 Codex 和 Claude Code 构建 iOS/macOS 应用的经验，推荐 5 套面向 Xcode 项目的 Agent skills：Paul Hudson 的 SwiftUI 基础系列、Antoine van der Lee 的构建优化 skill、Thomas Ricouard 的 OpenAI 官方 Codex 插件、Krzysztof Zabłocki 的规则驱动系统，以及作者自己的 AppCreator。核心结论：没有合适的 skills，Agent 会写废弃代码、报编译错误；先装一套，观察代码变化，再逐步叠加更多。

🔗 查看原文 — x.com

4. 正在冲击前端 Web 开发领域的小行星 / The Asteroid Currently Hitting Frontend Web Development

作者观察到，前端领域众多知名教育者正在退出或转向谈论 AI，而他自己实测发现：过去连资深开发者都会反复栽跟头的 Chrome 性能难题，如今 Claude 也能给出出色解答。文章剖析了前端教育面临的三股逆风：前端代码交给 Agent 风险更低、开发体验（DevExp）不再关键、Web 标准重心转向新能力。同时给出三个积极方向：教 Agent 全局观（如用 MPA 取代 SPA）、打造对 Agent 友好的网站、为 AI 生成的"承重墙"代码提供专家咨询。作者以小行星撞地球自比，主张直面这场变革而非否认。

🔗 查看原文 — nolanlawson.com

5. 编程的终结 / The End of Programming

Bun 1.4 用 11 天由 AI Agent 完成 Zig 到 Rust 的重写（超 100 万行代码），作者据此判断：人手写代码、人审代码的编程时代正走向终结。作者用每周 Fable 配额在 14/28 小时内完成 InfluxDB 的 Iceberg 集成与边缘数据复制系统两个复杂特性，验证了高阶指挥加少量监督即可产出可用软件。随着模型能力提升与 token 成本暴跌，未来多数软件将由 Agent 编写，人只审查最终结果。

🔗 查看原文 — pauldix.com

🌱 职场与个人成长

6. 走出洞穴 / Exit the Cave

本文反思流行的"闭关苦磨"洞穴情结：私下孤独努力固然舒适，却容易让人把努力误当作进步，用可控的投入替代无法保证的结果，甚至活在算法与 AI 加固的妄想里。作者以近二十年前的摔跤经历为镜：他苦练技术与体能却始终难求一胜，根源在于他真正想要的是"不让团队输"以逃避羞耻，而非胜利本身。结论是，任何值得的追求都需要现实的检验——作家需要读者，创业者需要客户，运动员需要比赛。与其像懦夫般在暗处无休止地训练，不如带着勇气走进真实世界，哪怕被当众压倒在地。

🔗 查看原文 — turtlespace.blog

7. 把 AI 挡在你的（Obsidian）仓库之外 / Keep AI Out of Your (Obsidian) Vault

作者认为在 Obsidian 仓库中大量用 AI 生成摘要、自动整理笔记是一条死胡同：生成内容会淹没你自己的思考，自动建立的连接也并非你亲手所建，难以带来真正洞见。AI 更适合用于查找相关笔记这类高级检索，敏感笔记宜搭配本地模型。你的笔记就是明天 AI 的 Prompt，亲手构建的笔记网络才会随时间复利增长。

🔗 查看原文 — ssp.sh

8. 快速学习的原则 / The Principles of Learning Faster

消费信息多并不等于学得多，真正拉开差距的是学习方式。文章给出七条原则：在实践中学习、缩短反馈循环、搜索前先自己挣扎、按需学习、提取胜过识别、先连接再收集、让学习产生复利。核心是把信息转化为理解，再把理解转化为行动；做得足够久，学习本身就会越来越容易。

🔗 查看原文 — x.com

9. 最不容易被 AI 取代的工作可能是写作 / The Safest Job from AI May Be Writing

AI 已能高效生成代码，写出的文章却依旧机械空洞。作者认为 LLM 短期内难以威胁优秀写作者：文本模型在表达与真实感上已撞上能力天花板；写作是无明确规格、无客观验证的 wicked problem，甚至可能是 AI-complete 问题，需要实时模拟读者心智；按比较优势理论，当 AI 垃圾内容淹没网络，真实的人类声音便成为无法伪造的高成本信号。写作者无需改变工作方式即可受益，而程序员则日益逼近被淘汰。

🔗 查看原文 — muratbuffalo.blogspot.com

📦 产品与设计

10. 我是如何用 AI 做设计的 / How I Design with AI

一位并非设计师出身、痛恨垃圾产物（slop）的工程师，总结出让产品设计"去 slop 化"的 7 条方法：先列出设计约束、再从整体出发考虑方案，避免打地鼠式局部修补；主动删掉 Agent 堆砌的多余元素；在设计工具（如 Figma）中迭代，警惕原型引力；使用可复用组件与 /showcase 页面；借助预览部署用真实数据验证；大胆借鉴优秀产品的现成解法；并通过反复尝试与批评打磨个人品味。核心结论：约束优先、克制加法、用真实数据检验，才能避免做出千篇一律的 AI 味界面。

🔗 查看原文 — x.com

11. 可塑软件 = 坚实基座 + 自定义代码 / Malleable Software = Solid Bases + Custom Code

作者基于 22 年生产力工具市场的观察，追问 AI 时代的可塑软件热点在哪里：是从零 vibe-code，还是拥有可用自定义代码定制的坚实基座？结论是"80% 坚实基座 + 20% 自定义代码"才是理想解：基座覆盖数据库、权限、历史、协作等所有团队相同的部分，自定义代码负责团队独有的界面、业务逻辑与连接。从零构建、vibe-code 平台、低代码、可塑工具与专门工具五条路线各有短板，正共同向这块领地移动，其中可塑工具最可能率先到达。选型时应优先选定基座，而不是界面。

🔗 查看原文 — mdubakov.me

2026-08-24 · 共 8 篇

🤖 AI 编程

1. 如何构建一套可持续维护的评估集 / How to Build an Eval Set You Can Maintain

本文回答"已有 traces，如何搭建 evals"这一问题：先用错误分析（error analysis）从真实失败中挖掘候选指标，再区分一次性修复与泛化问题、把每个指标绑定到一个具体决策、并考虑评估器的运行成本，从而筛选出值得长期维护的指标集。指标分三类：目标指标、护栏（guardrails）指标与运营指标，在保证可见性的前提下越少越好。最后通过定期重跑错误分析、退役失效指标、防止 Goodhart 定律式的过拟合，让指标集保持鲜活。

🔗 查看原文 — x.com

2. 软件工厂需要更快的评审循环：进一步优化从 PR 到合并的路径 / The Software Factory Needs a Faster Review Loop: Further Optimizing the Path from PR to Merge

在 AI 原生的工程组织中，生成代码已不再是交付软件最慢的环节，评审、验证、修复与人工决策才是瓶颈。独立的 AI 编码工具或许能带来 30–40% 的提速，但要在吞吐量上实现阶跃式提升，必须优化代码写完之后的一切环节。Augment 把此前 3 倍代码产出的评审系统扩展为完整的 PR 到合并循环：多个专职 Agent（风险分析、逐行评审、修复、运行时验证等）持续处理机械性交接工作，人类提供判断与知识传递并保留最终合并决策权。这就是循环工程（loop engineering）：改进把生成代码转化为已验证、可合并变更的完整系统，而不是孤立优化某个单一工具。

🔗 查看原文 — x.com

3. 编写优秀的评估器 / Writing Good Evaluators

如何编写可信的评估器：能用确定性代码评估器（快、便宜、结论稳定）就优先用代码；评估器要细粒度，每种失败模式一个二元或分类评判，而不是综合打分的"上帝评估器"；输入应衡量环境中的实际结果而非对话中的声明。写 LLM-as-a-judge 提示词前先标注 10-20 个真实案例，提示词按背景、精确标准、标注示例、先推理后结论、留出 "unknown" 出口来组织；最后用标注案例校准评判器，上线后持续抽样复核其结论。

🔗 查看原文 — langfuse.com

🧭 战略与协作

4. 既要 AI-Native，也要 AI-Proof / Be AI-Native and AI-Proof

在 AI 时代，仅靠"更好的智能"与"行政自动化"的价值主张会随前沿模型进步而不断失守，价值正转向"智能 + 自动化 + 问责"。问责所需的执照、监管、线下运营与风险承担能力位于模型层之外，前沿模型公司既无暇也无意包揽。文中给出三类既高度 AI-Native 又 AI-Proof 的医疗健康产品形态：提供诊疗与线下服务、承担财务风险、开发受 FDA 监管的产品。

🔗 查看原文 — x.com

5. 让智能支出恰到好处 / Right-Sizing Your Intelligence Spend

前沿模型的智能已突飞猛进，但经济中大多数工作（理赔、护理、物流）需要的不是发现未知，而是在组织已知范围内做出正确决策。每个工作负载都有智能门槛：跨过之后瓶颈转为上下文与执行，边际推理 token 的价值可能趋近于零。实验室靠多卖智能取胜，企业靠少用智能取胜，双方激励根本冲突。未来将是海量路由器与网关、混合工作负载默认化：困难新颖的部分交给前沿模型，简单、重复、私有的部分留在本地。进步的衡量标准是每次成功结果所消耗的智能趋近于零。

🔗 查看原文 — x.com

📦 产品与设计

6. Mole 出 Mac 版后，用户教会了我做产品 / What Users Taught Me About Building a Product

Tw93 回顾把开源 CLI 工具 Mole 做成 Mac 付费软件的三个月：AI 时代磁盘被编译产物、工具旧版本和模型文件撑爆，清理工具最核心的决策是"不删什么"——模型与 AI 会话记录写死保护、删前逐项确认、宁可漏删不误删。而最大的产品收获几乎全部来自用户邮件：默认摄氏度、浅色模式也是无障碍需求、定价数字影响信任感。他坚持手工回邮件（退款率低于 0.8%），认为代码能力只占做产品的三成，"不做什么"远比"做什么"重要。

🔗 查看原文 — x.com

🌱 职场与个人成长

7. 成为更好作家的黄金法则 / The Golden Rule for Becoming a Better Writer

成为更好作家的唯一黄金法则：尽可能多读，读得广、读得好。作者认为写作没有统一蓝图，但阅读无可替代——每本书都在教写作技法，类型之外的阅读带来源源不断的灵感，并重塑大脑的专注力与想象力；而数字成瘾会摧毁阅读型大脑，阅读所需的持续专注恰是写作的根基。想写作却称"太忙没时间读书"的人，应放下手机每晚读一小时书，几周即可重塑大脑、练出写作耐力。

🔗 查看原文 — nappertime.com

📥 其他

8. 新到手的 Linux 服务器，我这样设置 / How I Set Up a New Linux Server

一篇个人向的 Linux 服务器初始化 SOP：先用 YABS 脚本"验牌"，核对 CPU、磁盘与带宽是否与服务商承诺一致；再通过一键 DD 脚本或自定义 ISO 重装纯净系统；随后创建非特权用户并配置 sudo、更新系统安装基础软件，最后完成 SSH 加固、Fail2ban 与 nftables 防火墙设置。适合作为快速部署环境的速查手册。

🔗 查看原文 — blog.dejavu.moe

2026-08-20 · 共 10 篇

🤖 AI 编程

1. AI 正在消除软件工程的中级工程师 / AI Is Removing the Middle Class of Software Engineering

AI 移除了代码产出的限速器，让工程文化薄弱的项目以前所未有的速度走向失控，2.5 万行的 PR 与谁也解释不清的架构正在成为常态。修复一个糟糕决策的代价远高于制造它，团队只能不断让 LLM 兜底。结果是从业门槛被抬高到"当下最好的模型能做的事"，优秀工程师变得更稀缺也更值钱，而缺乏判断力的人越来越难被雇佣——这一趋势终将蔓延到绝大多数知识工作。

🔗 查看原文 — blog.florianherrengt.com

2. Jeff Dean 的「1% 法则」：AI 时代，真正稀缺的已经不是写代码 / Jeff Dean's "1% Rule": What's Truly Scarce in the AI Era Isn't Writing Code

一场对谈，一条主线：当 AI 接管「执行」，工程的重心正在向上移动。Jeff Dean 提出「1% 法则」——不要站在基础模型能力扩张的正前方，而去寻找今天最强模型成功率只有 0%～1% 的问题，那里才是小团队建立工程壁垒的地方。模型只是系统的一个乘数（Agent 能力 = Model × Context × Tools × Skills × Evaluator × Orchestration），堆 Agent 不如做好反馈闭环；AI 越会写代码，Specification 反而越重要。代码不再稀缺后，真正稀缺的是 Taste：你决定让机器去生产什么。

🔗 查看原文 — x.com

3. Codex 中的实用多 Agent 编排 / Practical Multi-Agent Orchestration in Codex

Codex 的 Multi-Agent V2 工具让 GPT-5.6 Sol 与 Terra 能自然地委派任务、同步进展、协同完成复杂工作。文章给出实用配置：按推理力度分工（Scout 用 Light、Worker 用 Medium、Smart worker 用 High），默认并发四个 Agent；用 fork_turns: "none" 给 Agent 干净上下文，为叶子 Agent 设边界并写明安全限制；最后把这套模式沉淀成 skill，并动手实验各参数。

🔗 查看原文 — x.com

4. AI 工程技能图谱 / The AI Engineering Skills Map

吴恩达团队基于超过 10,000 条招聘信息、数十次专家访谈与问卷调研，总结出四项最重要的 AI 工程技能：构建与部署 AI 应用（以 eval 与错误分析让不可预测的输出变得可控）、软件工程基础（识别并做出高质量权衡）、使用编码 Agent（管理上下文、编排多 Agent 协同）、塑造构建方向（以产品意识决定 spec 内容）。这些技能属于所有开发者，而非仅限"AI 工程师"职位；支撑它们的是持续学习的心态。

🔗 查看原文 — x.com

🌱 职场与个人成长

5. 给我 20 分钟，我让你无法被操纵 / Give Me 20 Minutes and I'll Make You Impossible to Manipulate

思维有三个层级：NPC（盲从权威）、主角（独立理性）、程序员（多视角元认知）。社交媒体的算法靠激怒你的内容牟利，让人陷入"智力肥胖"与低层级反应式思维。出路不是逃离社交媒体，而是每天坚持四个 10 分钟习惯：提问质疑确定性、主动筛选信息源、读真正的长内容、亲手创作输出，以此重塑认知架构，让问题从痛苦变为值得享受的谜题。

🔗 查看原文 — x.com

6. 更好决策的原则 / The Principles of Better Decisions

更好的决策不来自更多信息，而来自更好的思维方式。文章提出七个思维模型：第一性原理、机会成本、二阶思维、复利效应、激励、概率思维与逆向思维。核心结论是：每个决定都在塑造你的长期轨迹，与其追求确定性，不如持续提高胜率、避开必然失败的行为。

🔗 查看原文 — blog.satd.tech

7. 人即是环 / The Human Is the Loop

作者从一段远离 AI 的假期归来，意识到自己过去大量、频繁地使用 AI 其实多半并不必要，甚至养成了依赖，削弱了好奇心、自信与判断力。文章反思了在 agent、自动化和"生产力衔尾蛇"上的过度投入，并决定今后有意识地取舍何时用、何时不用 AI。核心结论：人不应该被困在 agent 的循环里——人本身就是循环，agent 只是偶尔、审慎地被拉进来协助。

🔗 查看原文 — brentfitzgerald.com

8. 流程作为动机的代理 / Process as a Proxy for Motivation

与其依赖动机去实现目标，不如建立流程（提前定好的规则）来替代动机。作者用横穿苏格兰选路、火车通勤保持高效两个例子说明，单凭意志力难以达成抽象目标，而固定流程能省去反复决策的负担。这一思路同样适用于软件开发中的 Agile、Scrum 等实践。读者应带走的方法是：把宏大目标拆解为可执行、无需多想的简单规则。

🔗 查看原文 — bengodfrey.dev

👥 带人与领导力

9. 团队的天花板，取决于谁会听、谁在听、怎么听 / A Team's Ceiling Depends on Who Listens, What They Hear, and How They Listen

聆听不止是沟通技巧，更是组织智慧的源头。文章提出聆听的三个层次：聆听他人（尊重与重视，建立合作伙伴关系）、聆听自己（放下内在的评判与防御性聆听）、聆听集体的共享意义（从多重视角中拼出完整的"大象"）。团队的天花板取决于谁会听、谁在听、怎么听；培养集体聆听的能力，才能解锁团队对话与共创的力量。

🔗 查看原文 — mp.weixin.qq.com

📦 产品与设计

10. YC 对话 AI 原生设计工具 Paper 创始人：AI 永远学不会品味？不，设计师暂时安全 / YC in Conversation with Paper Founder: Will AI Ever Learn Taste? No, Designers Are Safe for Now

YC 与 AI 原生设计工具 Paper 创始人 Steven Haney 的对谈。Paper 以 HTML/CSS 为渲染引擎，让 Agent 能像操作网页一样操作设计文件，形成"Agent 负责大量生成、人负责筛选与最终判断"的新工作流。针对"AI 味"，他的建议是"往回收"：减轻字重、字号压到三种、删掉多余的图标徽章——少即是多。设计在组织中的核心职能（探索问题空间、与利益相关方沟通）依然重要，设计师暂时安全。

🔗 查看原文 — mp.weixin.qq.com

2026-08-12 · 共 8 篇

🤖 AI 编程

1. 每位 AI 工程师都应了解的自我改进 Agent 循环 7 条法则 / 7 Rules for Self-Improving Agent Loops

本文指出：当编码 Agent 通过"运行-打分-修订"循环自我改进时，真正的工程已从编写产物转移到定义"好"的度量——循环能自动化一切，却无法告诉你"更好"的含义。文章结合开源工具 agents-cli 介绍循环实战（generate / grade / compare），并给出 7 条让循环保持诚实的法则：从单个用例起步、让评判者给出理由、用确定性代码替代评判、给行为而非路径打分、把不稳定用例当作发现、不让提案者移动门槛、自动优化只做一次。核心结论：Agent 不必完美，只需可被改进。

🔗 查看原文 — x.com

2. Anthropic 循环设计指南：拆解 AI 新范式 Loop / Anthropic Loop Design Guide

Claude Code 团队给出 Loop 的权威定义——Agent 重复执行工作周期、直到满足特定停止条件，并按触发方式与停止条件将其分为四类：轮次循环（用户逐轮引导）、目标循环（/goal 设定可验证的退出标准）、时间循环（/loop、/schedule 定时触发）、主动循环（事件驱动 + 动态工作流，可长期运行）。文章同时给出两条实操建议：用干净代码库、自我验证技能与第二智能体审查来保证质量；按任务选模型、设清晰停止标准、试点后再规模化来控制 Token 消耗。一份"何时放手、放手到什么程度"的选型指南。

🔗 查看原文 — mp.weixin.qq.com

3. 更新即加固：AI 时代让 Chrome 与网络更安全 / Stronger with Every Update

Chrome 安全团队借助 Gemini 等 LLM 在漏洞发现、分诊、修复、发布与应用全链路实现大规模自动化：最近两个里程碑修复的 1072 个安全 Bug 已超过此前 23 个里程碑修复量之和。文章还阐述了 MiraclePtr、spanification、Rust 迁移等内存安全策略，CQ 阶段的语义拦截，以及第三方依赖自动更新、动态打补丁、零窗口自动重启等机制，强调"速度叠加结构性防御"是 AI 时代防御者保持优势的关键。

🔗 查看原文 — blog.google

4. 为什么 Go 是 AI 辅助软件工程的理想语言 / Why Go is Ideal for AI-Assisted SE

当 AI 把软件工程的重心从"编写"转向"审查与维护"，编程语言的关键价值也随之改变。Google 这篇博客论证：Go 之所以是 AI 辅助开发的理想语言，是因为它从设计之初就为大规模、长期协作而生——严格的静态类型与编译器充当 Agent 代码的安全网，统一的工具链与标准库带来跨生态的一致性，对可读性的坚持让人类能快速验证 AI 输出，而兼容性承诺与确定性的现代化工具则保证了代码库在 AI 高速演进下仍然可维护。读者应带走的核心信息是：在 AI 时代，可预测、可验证、可维护的语言特性才是真正的生产力护城河。

🔗 查看原文 — developers.googleblog.com

5. 为什么软件工厂会失败 / Why Software Factories Fail

本文探讨"灯下黑"软件工厂的失败原因：AI 编码 Agent 缺乏长期维护代码库质量的能力。现有基准测试只关注测试是否通过，无法惩罚侵蚀可维护性的糟糕设计。解决方案是回到人类主导的代码审查，通过产品需求、系统架构、程序设计和垂直切片四个阶段的前置规划，在 AI 辅助下实现 2-3 倍提速的同时保持接近人类水平的代码质量。

🔗 查看原文 — github.com

6. 让 AI 在复杂代码库中工作 / Making AI Work in Complex Codebases

本文讨论如何通过「频繁有意压缩」（Frequent Intentional Compaction）来管理 AI 编码 Agent 的上下文窗口，使其能够在大型既有代码库中高效工作。核心流程为研究、规划、实施三步，配合高杠杆的人工审查与紧凑化产出，避免上下文过载与重复劳动。作者展示了在 30 万行 Rust 项目（BAML）中提交 PR 并通过专家审核的案例，强调人工审查必须聚焦于研究与计划等高杠杆点，而非逐行代码。这不是魔法提示词的替代，而是工程流程的重构与团队协作范式的转型。

🔗 查看原文 — github.com

🌱 职场与个人成长

7. 如何在 AI 大规模裁员潮中活下来 / Surviving the AI Mass-Layoff Wave

作者 Dan Koe 认为，AI 并非真正的威胁，真正的威胁是"你的生存完全依赖于他人"。摆脱"工资奴役"的解药不是打工或反 AI，而是让自己"不可被雇佣"——投身属于自己的事业。文章给出成功的五种成分（能动性、品味、说服力、坚持、迭代），并落到三条行动路径：切换环境以重塑身份、选择反馈贴近现实的载体（媒体优于代码）、用 15 分钟挖出自己独特的"原材料"并立刻发出第一篇内容。核心观点：AI 时代真正的护城河，是那些无法被商品化的、属于你自己的判断与表达。

🔗 查看原文 — x.com

📥 其他

8. 压缩即预测 / Compression is Prediction

本文揭示了压缩器与 LLM 本质上在解决同一个问题：预测下一个符号。作者通过游程编码、算术编码、熵与上下文模型等基础概念，说明概率分布越倾斜、上下文越充分，压缩效果就越好；而 LLM 正是当下最强的下一符号预测器，因此天然就是极佳的压缩器。尽管模型体积与算力开销让 LLM 难以在实际工程中取代 gzip，但两者背后其实是同一套数学。

🔗 查看原文 — ngrok.com

2026-08-10 · 共 5 篇

🤖 AI 编程

1. 我们如何构建软件工厂，把 Astro 的 GitHub issue 数量降到零 / How we built a software factory to drive Astro's GitHub issue count to zero

Astro 用一组运行在 GitHub Actions 中的隔离 AI 子 Agent 自动化 issue 分诊：读取报告、沙盒复现、定位根因、发布预览供报告者验证，确认后开启 PR。几个月内未关闭 issue 从 200 多个降到约 30 个，预计下个月内清零。底层运行时已开源为 Flue 框架，triagebot-action 可直接复用或 fork；作者强调，Agent 的失败往往暴露的是代码抽象、文档与测试方面的问题。

🔗 查看原文 — blog.cloudflare.com

🛠️ 工程方法

2. 「代码从来都不是最难的部分」是对所有程序员的侮辱 / "Code was never the hard part" is an insult to all programmers

"代码从来都不是最难的部分"这一说法是对程序员群体的侮辱。软件开发既需要精湛的编码技艺，也需要深入理解客户需求——两者不可偏废。面对 AI 带来的行业剧变，与其把头埋进沙子自我安慰，不如主动适应变化：资深开发者应拓宽视野，学习用户体验与商业策略；初级开发者则需夯实计算机科学基础。无论如何，不要将你的理解力、判断力和品味外包给 AI。

🔗 查看原文 — blog.senko.net

3. 软件关注的是人，而非代码 / Software is about people, not code

作者回顾自己初入行时认为软件开发就是写代码，于是专注于风格指南、新技术和设计模式。但后来他发现，软件项目的成功更多取决于人而非代码：软件为人而存在，用户只关心能否完成任务，再优雅的代码若做错了事也是徒劳。代码只是通用工具，必须解决真实的人的现实问题。

🔗 查看原文 — letterstoanewdeveloper.com

📦 产品与设计

4. 从你的门铃到你的家庭网络 / From your doorbell to your home network

本文对 Eufy Security 视频门铃生态系统进行了深度逆向工程分析。研究发现：Homebase 创建的隐藏 Wi-Fi 网络（OCEAN_XXXXXX）易受去认证攻击，且该网络未做隔离，攻击者接入后可直接访问家庭网络中的其他设备（如路由器）。声音同步协议被完全逆向并成功利用——通过伪造音频即可让门铃连接到攻击者控制的 Wi-Fi。此外，门铃闪存中的加密配置文件（es_config）可通过硬编码密钥解密，从而提取隐藏网络的 SSID 和密码。整体而言，该生态系统的安全设计存在多处可利用的薄弱环节。

🔗 查看原文 — adepts.of0x.cc

🌱 职场与个人成长

5. 为什么科技行业人人都这么悲伤？ / Why Is Everyone In Tech So Sad?

作者认为，知识工作者集体陷入存在性焦虑，根源在于"工作主义"用工作取代了宗教式的意义供给。AI 的引入把工作进一步抽象、剥离了人与人协作的"混乱中段"，正悄然瓦解这套信仰体系。当顶尖人才从幻象中醒来、却没有经济可行的替代方案时，整个行业与社会都将被迫面对这场价值重构。

🔗 查看原文 — noemamag.com

2026-08-06 · 共 9 篇

🤖 AI 编程

1. 如何递归地改进你的 Agent / How to Recursively Improve Your Agents

本文介绍如何通过递归自动改进（RAI）循环提升 Agent 质量：编码 Agent 读取目标 Agent 的指令、挖掘使用数据以推导探针，再针对线上 Agent 运行探针、审查日志并迭代修改指令、工具与参数，直至每个探针通过。与发散的 RSI 不同，RAI 是一个收敛过程，将 Agent 拉向其自身规范，适合生产级软件。作者还给出了从搭建平台、创建 Agent 到运行改进循环的完整步骤，并推荐在部署前做一次通宵运行以覆盖罕见边缘情况。

🔗 查看原文 — x.com

2. 推出 Cloudflare Agents / Introducing Cloudflare Agents

Cloudflare 推出 Cloudflare Agents 平台，从可观测性切入，把已部署的 Agent 会话整合到统一体验中。首发功能 Agent 追踪兼容 OpenTelemetry，支持 Think、Flue、AI SDK，将模型调用、工具执行、token 使用量等 span 与 Workers 基础设施关联起来。仪表板新增 Agents 视图，可重放会话或查看执行瀑布图。Beta 期间免费，2026 年 10 月起并入 Workers Observability 定价。

🔗 查看原文 — blog.cloudflare.com

3. Pi：极简与高性能 / Pi, Minimal and Performant

Pi 通过刻意极简（仅 4 个工具、system prompt 不足 1,000 tokens）实现了更低的成本与更高的性能。Databricks 的 benchmark 显示，搭配 Opus 4.8 时 Pi 的通过率最高，且成本显著低于 Claude Code 和 Codex；Shopify 则通过 pi-autoresearch 扩展验证了 Pi 的可扩展性优势。随着前沿模型对终端环境驾驭能力的提升，极简、克制上下文的 harness 正成为更优选择，对本地模型尤为友好。

🔗 查看原文 — earendil.com

4. Agent 开发生命周期（ADLC）已登陆 Cloudflare / The Agent Development Lifecycle Has Arrived on Cloudflare

AI 让代码"实现"从 SDLC 中最慢最贵的环节变成最快最便宜的环节，却也让审查、部署、维护不堪重负。Cloudflare 据此提出用 Agent 开发生命周期（ADLC）取代传统 SDLC，让 Agent 端到端驱动"软件工厂"，而非只负责生成代码。核心论点：要让 Agent 安全接管全流程，平台必须做到可编程、可水平扩展、可复现、实时推送、原子化、受控授权且能自我改进。Cloudflare 以 Workflows（编排复杂步骤、派生容器与 Agent）加 Artifacts（代码存储层）为核心原语，覆盖从规划到退役的每个阶段。

🔗 查看原文 — blog.cloudflare.com

🛠️ 工程方法

5. 关于软件工程与生成式 AI 的八大迷思 / Eight Myths on Software Engineering and GenAI

本文基于大规模研究与实地观察，剖析生成式 AI 在软件工程中的八大迷思。开发者实际仅有约 14% 的时间在编写代码，AI 代码生成所能触及的工作面比想象中窄得多；以代码行数衡量成效既无统计效度，也偏离软件质量的真正目标；AI 的收益高度依赖任务类型、开发者经验与上下文，而信任、合规、遗留系统与组织流程等结构性因素，决定了 AI 不会自动转化为生产力，也无法让企业复制创业公司的速度。读者应跳脱炒作与单一指标，从组织层面重塑工作流与评估方式。

🔗 查看原文 — queue.acm.org

6. Cloudflare 如何使用 AI 推行工程标准 / How Cloudflare Enforces Engineering Standards Using AI

Cloudflare 将分散的工程文档重构为受治理的标准库 Cloudflare Codex，使用 RFC 2119 的 SHOULD/MUST 关键字，并通过 AI 代码审查器、规格审查 agent 和事故报告审查 agent 在开发流程各环节自动检索并执行这些标准。过去四个月已标记近 25 万处违规、阻止 16,000 次合并、评估约 600 份技术设计，未来计划扩展至产品、安全、合规等更多领域。

🔗 查看原文 — blog.cloudflare.com

7. Palantir CEO 亲自谈 FDE：买 Token 创造不了价值 / Palantir CEO on FDE: Buying Tokens Creates No Value

Palantir CEO Alex Karp 在两场 CNBC 专访中直言：企业界烧着 token 却拿不到产出，还把商业机密拱手送给大模型厂商。他强调真正持久的价值不在「PhD 团队 + 大模型」（壁垒最低），而在硬编码进系统的基础设施、作为应用层的 Ontology，以及把工程师派进战区与车间的 FDE 前沿部署模式——LLM 是概率系统，造不了火箭；要让它在关键基础设施里安全落地，必须让客户自己掌控算力、权重与数据。

🔗 查看原文 — mp.weixin.qq.com

🌱 职场与个人成长

8. 大多数技术革命让员工的工作变得更糟，AI 可能是个例外 / Most Tech Revolutions Made Work Worse for Employees. AI Could Be the Exception

PC、电子邮件和智能手机等历次技术革命在加速工作的同时也堆叠了更多任务，公司受益多于员工。AI 的不同之处在于：它不仅提速，还亲自承担一部分工作。作者认为，节省下来的时间不会简单地被同样填满，而会投入思考、协作与质量提升，AI 有望像桌面排版一样在整个经济范围内引发一场质量繁荣。

🔗 查看原文 — thisandthat.chat

📥 其他

9. 一个词是怎么死的 / How a Word Dies

本文以「信用超发」为题，梳理中国科技行业一批被用脏、用死的词——「遥遥领先」「自研」「纯血」「开源」「生态」。作者把责任按「发行顺序」拆成三代：发明民族叙事语法者、抹平来源并焊死证伪通道者、被囚徒困境裹挟者，并指出真正的代价不是某家公司变坏，而是「诚实变成竞争劣势」、最挑剔的用户作为行业免疫系统悄然流失。文末以指鹿为马、王莽符命、宋真宗封禅、科场舞弊等史例佐证：损害制度信用的罪，历来判得比贪钱更重。

🔗 查看原文 — x.com

2026-08-04 · 共 6 篇

🤖 AI 编程

1. 开发工具必须开源 / Devtools Must Be Open Source

在 Agent 时代，开发工具必须开源。借助两条提示词——本地下载并修改源码、每夜自动 rebase 上游变更——Agent 能让软件个性化的一次性成本和持续维护成本同时消失，使传统的插件系统与配置文件变得不再必要。开源 Agent（如 Shelley、Pi、Codex）因此可被深度个性化，而闭源的 Claude Code 则做不到。核心结论：可个性化的软件需要源码，闭源开发工具将逐渐失去竞争力。

🔗 查看原文 — blog.exe.dev

2. LLM 回报专业知识 / LLMs Reward Expertise

本文认为，决定 LLM 提示词效果的真正关键不是所谓的"提示词技巧"，而是对所问领域的专业积累。以数学家陶哲轩与 ChatGPT 的对话为例：他能从模型回答里提炼要点、提出替代思路、识别异常之处，靠的是对数学本身的深刻理解。作者作为程序员的实践同样印证了这一点——对代码库越熟悉，就越能把 LLM 逼出更高水准的产出。结论是：很多任务上瓶颈在人而不在模型，领域专业知识不会因为模型变强而贬值。

🔗 查看原文 — seangoedecke.com

3. 在任何地方预览你的 iOS 构建版本 / Preview Your iOS Builds Anywhere

Sqim 是一款轻量级 iOS 应用，让你随时随地在 iPhone 上预览 Swift 构建版本。通过 Homebrew 安装 sqim CLI 后，即可让 Agent 将构建推送到手机，无需 VPN 或 Tailscale 登录。所有项目构建版本均可通过网页仪表板重新访问，适配 Codex、Claude Code、Cursor 等主流 Agent 工具。

🔗 查看原文 — sqim.dev

4. Tilde：构建云端 AI Agent 的极速 Harness SDK / Tilde — A Harness SDK for Cloud-Deployed AI Agents

Tilde 是一款面向云端部署 AI Agent 的 harness SDK，作者把一个优秀 harness 的核心要素拆解成可按需组合的组件——工具（MCP 服务器 + 原生 HTTP 反向代理 + 凭证管理）、ChatKit（Slack/GitHub 等集成）、以及集中化的记忆与权限管理。文章用一个 GitHub PR 代码评审 Agent 做实战演示：开发者只需专注系统提示词与 git diff 分析循环，沙箱检出、凭证隔离、行内评论等其余环节全部由 SDK 接管，几分钟即可部署到 Vercel 与 Tilde。

🔗 查看原文 — trytilde.ai

🛠️ 工程方法

5. 形式化验证迎来拐点：AI 正在重构供需曲线 / Formal Verification at an Inflection Point — AI Reshapes Supply and Demand

本文论证 AI 对形式化验证是一场典型的双重供需重构。需求端：AI Coding 加速代码生成，却没同步提升审查与验证能力——AI 生成的代码越多，"确认实现是否可信"的人力越稀缺，验证诉求从"找 bug"扩展为"确认意图"，并随 Agent 行动半径扩大延伸到权限与策略正确性。供给端：AI 快速拉低证明搜索、规格草拟与错误修复成本，Theorem 提出的"任务级规格生成器"更可能把人工监督从 O(n) 压到接近 O(1)。结论是供给曲线将分段右移：智能合约、密码学、代码迁移等垂直领域率先产品化，通用证明能力长期商品化后，价值会迁移到领域规格、可信转换与开发工作流。

🔗 查看原文 — x.com

🏢 组织管理

6. DevOps 之父：发几个 Claude Code 账号不叫 AI 转型 / Patrick Debois — Handing Out Claude Code Licenses Isn't an AI Transformation

DevOps 一词的提出者 Patrick Debois 认为，企业买几个 Claude Code 许可证、搞几场培训并不等于 AI 转型。核心心态转变是：当 Agent 没达到预期，不要去改它生成的代码，而要改进"产出代码的整个系统"——Context、Harness 与循环。他主张把共享 Context、技能注册中心、评估系统与护栏集中到平台团队，形成可复用的"铺装路"，让一次优化在全员产生乘数效应；并强调超级个体救不了组织，真正的护城河是沉淀进 skill 与 Harness 的业务上下文。两个关键生产力指标：让 Agent 做对一件事所需的人工干预次数，以及共享系统的复用率。

🔗 查看原文 — mp.weixin.qq.com

2026-07-31 · 共 8 篇 · 整理自阅读记录

🤖 AI 编程

1. Agent Interaction Guidelines（AIG）— Linear Developers

Linear 提出的 Agent 交互指南：随着 Agent 大量承担软件的规划、构建、审查与部署，人机协作需要新的契约。AIG 定义了身份标识、状态透明、即时反馈、退出机制与委托模型等原则——Agent 必须清晰可辨、全程可审查、随时可终止，最终责任始终由人类承担。

🔗 查看原文 — linear.app/developers/aig

2. Anthropic 内部用了几百个 Skills，他们总结出了这 9 种最有效的类型

Anthropic 内部在 Claude Code 中运行数百个 Skill，梳理出 9 种最有效类型（库/API 参考、产品验证、数据获取分析、工作流规范化等）。Skill 本质是含脚本与资源的文件夹而非纯 Markdown；好的 Skill 清晰归属某一类别，配合负面示例与动态 Hooks 能显著提升 Agent 路由准确率。

🔗 查看原文 — x.com/gosailglobal

3. Shell + 技能 + 压缩：长期运行且真正发挥作用的代理的技巧

OpenAI Responses API 三项原语的最佳实践：用精心设计的 Skill 描述与负面示例提升 Agent 路由准确率；将模板与示例内置于 Skill 以压缩 Token；用容器复用与服务端压缩保障长期运行的连续性；再以两层 Allowlist 与 Domain Secrets 防范数据泄露。三者结合即可构建可重复、可隔离、长时运行的实用 Agent。

🔗 查看原文 — developers.openai.com

4. The AI Agent Complexity Ratchet：为何需要 90% 测试覆盖率

Garry Tan 通过两个开源项目（约 97 万行代码）的实践指出：AI Agent 让 90% 测试覆盖率成本归零，形成"复杂性棘轮"——系统质量只升不降。Agent 随代码自动编写测试，缺陷逃逸率降一个数量级。测试覆盖率不是虚荣指标，而是把混乱代码转化为可控系统的关键；不构建棘轮的 AI 项目终将崩溃。

🔗 查看原文 — x.com/garrytan

5. 一切都是拉尔夫循环（It's All Ralph Loops）

作者认为传统"搭积木"式软件开发已死，取而代之的是 Ralph 循环：把 LLM 视为新型可编程计算机，通过上下文工程编程"循环"，自动化工程师自身的工作职能，最终走向无需人力、自主演化产品的软件工厂。文中展示了 Loom 项目的自动验证与自愈能力，证明演化式软件愿景已成现实。

🔗 查看原文 — ghuntley.com/loop

6. 代理原生架构：代码编写完成后如何构建应用程序

Every 提出的 Agent 原生应用构建指南：让 Agent 成为一等公民。核心原则——工具必须是原子原语且能力与 UI 对等；功能即提示词描述的结果，由 Agent 在工具循环中执行直至达成；以文件系统作为通用接口；在有限上下文窗口内合理设计。该架构让 Agent 涌现出开发者未预见的组合能力。

🔗 查看原文 — every.to/guides/agent-native

🌱 职场与个人成长

7. How to Earn a Billion Dollars — Paul Graham

Paul Graham 基于牛津联盟演讲指出：成为亿万富翁无需作恶，关键只有两个数字——增长率和持续增长的时间。做出让用户喜爱并愿推荐的产品就能实现指数级增长（月增 15%，五年增长 4384 倍）。最好的创业想法往往来自和朋友做有趣的项目，理解用户真实需求（同理心）才是成功的核心。

🔗 查看原文 — paulgraham.com/earn

8. Maybe You Should Learn Something — Marginalia

鼓励成年人重新学习新技能——像素画、盲打、3D 建模、木工、一门语言皆可，每天 30-45 分钟足矣。关键在于接受初学时的挫败感：进步发生在睡眠而非练习当下。坚持数月跨过"糟糕之山"即进入实用的中级平台期；这是一项终身受益、且让人变得更有趣的长期投资。

🔗 查看原文 — marginalia.nu

技术选型 Spec

### 目标

一个纯静态、构建期解析的数字花园，CSS 响应式兼容 Web/移动端，承载四类内容（对应站点四大栏目）：

- **生活**（`flows`）：个人日常生活记录、旅行随笔、生活思考。
- **阅读**（`series`）：计算机领域优秀内容推荐（类似日报，链接到原文），以系列组织。
- **项目**（`posts`）：个人兴趣开发项目记录。
- **影集**（`albums`）：以旅行目的地为维度的摄影集，瀑布流展示、可放大浏览，支持滚轮/双击缩放、键盘 ←→ 与触屏左右滑动切换。

外加「关于」等静态页；站内另有「常青笔记」（`notes`，不进主导航）与标签 / 归档 / 知识图谱等发现入口。仅中文（单语言）。

---

## 实施现状总览

| 项                              | 状态   | 说明                                                  |
| ------------------------------ | ---- | --------------------------------------------------- |
| 仓库工程 `~/dev/wills-garden`      | ✅    | 基于 amytis v1.17.0；GitHub 私有仓库  |
| 四类内容 + 关于（中文）                  | ✅    | books 关闭；notes 存在但不进主导航                             |
| 影集系统（3 档图 / 瀑布流 / Lightbox）    | ✅    | 自包含内容层，见下文                                          |
| HDR 图片管线 `heic2uhdr.swift`     | ✅    | HEIC → ISO 21496-1 gain-map JPEG                    |
| Cloudflare R2（桶 + CORS + 自定义域） | ✅    | `blog-res.satd.tech`             |
| 主站托管                           | ✅    | 静态导出 `out/`；Cloudflare Pages 自动构建（push `main`）      |
| 评论 / 分析                        | ✅    | Giscus（独立公开评论仓库，与源码仓库解耦）+ Google Analytics |
| 海外节点加速                   | ⏳ 可选 | 已实现                                                 |

---

## 技术选型（已落地）

> 原「技术选型初版」的评审结论：核心方向全部成立，落地时栈与图片管线有细化。

- **框架**：Next.js 16（App Router）+ React 19 + Tailwind v4，`output: "export"` 纯静态导出，`trailingSlash: true`（页面导出为 `slug/index.html`，便于与同目录共存资源 / nginx 美化 URL）。运行时与构建工具：**Bun**。
- **内容**：MDX / Markdown 为主（gray-matter + Zod 在 `src/lib/markdown.ts` 校验，非法 frontmatter 构建期抛错）；保留 rST 渲染支持（Python docutils 桥，本站未用）。
- **渲染增强**：Shiki 构建期语法高亮（双主题，`globalThis` 单例）、KaTeX 数学、Mermaid 图、GitHub Alerts、代码块工具栏、沉浸式阅读模式（书籍章节 / 系列文章）。
- **搜索**：Pagefind（运行时加载 `/pagefind/pagefind.js`）。
- **生活记录中的图片**：直接存仓库，构建期 `copy-assets.ts` 拷入 `public/`，走 `next-image-export-optimizer` 优化。
- **影集图片**：量大，存 **Cloudflare R2**，经自定义域 `blog-res.satd.tech`（R2 直连，SSL 自动签发）提供；CDN 域名是构建期单一配置项（见下文）。
- **加速**：可选接入腾讯云 EdgeOne 海外节点作为前置 CDN，**无需改构建配置**（仅 DNS/回源层）；备案状态按当地要求处理。
- **基底**：基于 [hutusi/amytis](https://github.com/hutusi/amytis)。amytis 仓库无 LICENSE，本站仓库私有、个人自用合规；若日后公开需先与 upstream 确认授权。

---

## 内容模型与站点结构

导航（`site.config.ts`，按 weight 排序）：生活(`/flows`) · 项目(`/posts`) · 阅读(`/series`) · 影集(`/albums`) · 关于(`/about`)。

| 内容类型 | 目录 | 路由 | 说明 |
|---|---|---|---|
| 项目 / 文章 | `content/posts/` | `/posts/[slug]` | 独立文章或文件夹文章（`index.mdx`） |
| 系列 / 阅读 | `content/series/<slug>/` | `/<series-slug>/[slug]`（`autoPaths`） | 按文件夹自动归属；rST 兼容 |
| 生活 / Flow | `content/flows/YYYY/MM/DD.(md|mdx)` | `/flows/[y]/[m]/[d]` | 日更短记，带日历侧栏 |
| 影集 | `content/albums/<slug>/` | `/albums/[slug]` | **本站自研内容层**（见下文） |
| 常青笔记 | `content/notes/` | `/notes/[slug]` | 不进主导航，参与反向链接 / 图谱 |
| 静态页 | `content/*.mdx` | `/[slug]` | about / links / privacy 等 |

发现入口：标签(`/tags`)、归档(`/archive`)、作者(`/authors`)、知识图谱(`/graph`)。Feed：`feed.xml`/`feed.atom`（精选）、`all.*`（全量）、`flows/feed.*`；`sitemap.ts`；`search.json`。

URL 一律经 `src/lib/urls.ts` 的 `getPostUrl()` / `getSeriesCustomPaths()` / `getAlbumUrl()` 解析，不硬编码。`redirectFrom` 别名生成静态跳转页，便于改名 / 迁移路径后旧 URL 仍可达。

内容脚手架模板见仓库 `templates/`（post / flow / note / album / series-index / series-issue 等）。

---

## 技术方案细节

### 影集数据形态

三档图，均为 HDR-capable 的 gain-map JPEG（HDR 设备显示 HDR，其余回退 SDR，不破图）：

| 层 | 内容 | 命名规则 | 存放 | 入 git |
|---|---|---|---|---|
| 原图 | HEIC → gain-map JPEG（q95）；非 HEIC 原样拷贝（不缩放） | `<stem>-<hash>.jpg` | R2，永不改 | 否 |
| `-m` 中图 | gain-map JPEG，最大边 ≤ 2400（q90） | `<stem>-m-<hash>.jpg` | R2，永不改 | 否 |
| `-s` 缩略图 | gain-map JPEG，最大边 ≤ 800（q80） | `<stem>-s-<hash>.jpg` | R2，永不改 | 否 |
| manifest | 每图 `{ src, w, h, medium, thumb }`，路径用相对资源根的 stem | — | 仓库内 | 是 |
| 影集 MDX | frontmatter：`title / date / location / excerpt / poster / manifest / tags / featured / draft` | — | 仓库内 | 是 |

关键规则：

- 三档**各自独立 content-hash**，关联靠 manifest 的 `medium`/`thumb` 字段，不靠同名 hash。
- 处理顺序固定：**准备原图（HEIC→JPEG）→ 写 EXIF → 算 content-hash → 命名 → 上传**（hash 基于打标记后的最终字节）。
- `w/h` 是**显示尺寸**：`image-size` 取原始像素，再读 EXIF Orientation；90°/270° 旋转（值 5/6/7/8）时宽高互换。否则瀑布流会为竖图排出横框。
- 上传后永不覆盖；换图即换 hash 文件名。`--prune` 按 manifest 清理 R2 孤儿对象。
- **中图优化**：源文件最长边已 ≤ 2400 时跳过再编码，`medium == src`（绝不放大、绝不存重复字节）。
- **已知缺口**：`--prune` 只追踪 manifest 条目，不追踪 frontmatter `poster:` stem；与 manifest 条目不同的 poster 需手动清理。

EXIF 版权标记（`scripts/process-album.ts` 内置）：

- `Artist` = `will lao`
- `Copyright` = `will lao (https://blog.satd.tech)`
- `XMP xmpRights:WebStatement` = `https://blog.satd.tech`

> 说明： **gain-map JPEG**——因为 sips / ImageMagick 在缩放时会丢掉 Apple HDR gain map，只有自研 `heic2uhdr.swift` 能同比例缩放 base 与 gain map，保住 HDR。三档共用同一转换器（带最大边参数），HDR 源出 HDR、无 gain map 的源出 SDR。

### HDR 图片管线（`scripts/heic2uhdr.swift`）

iPhone HEIC 照片携带 Apple HDR gain map。`heic2uhdr.swift` 把它重新封装为 **ISO 21496-1 / Ultra HDR gain-map JPEG**：**ImageIO 解码**（base SDR 图 + gain map + tone-map 元数据），**libultrahdr 编码** ISO/MPF 容器。为什么要拆两步——ImageIO 的 writer（`CGImageDestinationAddAuxiliaryDataInfo`）只会写出 Apple 命名空间（`urn:com:apple:photo:2020:aux:hdrgainmap`）的 gain map，Safari 认、Chrome 的 Ultra HDR 解码器不认（它只认 ISO 命名空间 `urn:iso:std:iso:ts:21496:-1` + MPF 容器），所以 ISO 容器必须由 libultrahdr 编码。

- **Safari（macOS Sonoma+ / iOS 17+）和 Chrome（116+）都显示 HDR**，其余浏览器自动回退 SDR，单文件兼顾两端。
- 缩放时同比例缩放 base 图与 gain map → 中图 / 缩略图同样保 HDR。
- 依赖系统 `swift`（Xcode CLT）与 `libultrahdr`（`brew install libultrahdr`，提供 `ultrahdr_app`）。

### 域名与 CDN

| 域名                   | 用途              | 回源                           |
| -------------------- | --------------- | ---------------------------- |
| `blog.satd.tech`     | 主站（HTML/JS/CSS） | Cloudflare Pages             |
| `blog-res.satd.tech` | 影集图片资源          | Cloudflare R2（自定义域，SSL 自动签发） |

- `NEXT_PUBLIC_RESOURCE_BASE`（默认 `https://blog-res.satd.tech`）为**构建期唯一配置项**；manifest 与 poster 只存相对资源根的 stem，组件运行时由 `resolveAsset()` 拼接。换 CDN 域名只改这一处。单影集可在 manifest 顶层用 `resourceBase` 覆盖（含 `""` 表示走本地 `public/`）。
- 当前为 **Cloudflare 原生全球分发**（可用，大陆体验一般）。
- **可选**：接入 EdgeOne 海外节点做加速（备案状态按当地要求处理）——两域名均经海外节点；`blog-res` 回源 R2、`blog.satd.tech` 回源 Pages，回源与缓存按 CDN 常规配置。`NEXT_PUBLIC_RESOURCE_BASE` 域名不变，EdgeOne 仅前置加速，无需改构建。

### 相册与渲染

- **影集列表页**（`/albums`）：卡片网格，以 `poster` 为封面（`AlbumCard` 用原生 `<img>`，绕过 `next-image-export-optimizer`——poster 在 R2，构建期不该被抓取），并复用为 `og:image`。
- **影集内部**：`react-photo-album` 的 `ColumnsPhotoAlbum`（瀑布流）显示 `-s` 缩略图；响应式列数（宽 <480→2 列，<900→3 列，否则 4 列）。点击任意图打开 Lightbox。
- **Lightbox**（`src/components/albums/Lightbox.tsx`，基于 **PhotoSwipe v5**）：
  - **渐进加载**：每项把 `-s` 缩略图作为 PhotoSwipe 原生 `msrc` 占位图秒出；全分辨率图加载完成后无缝替换（无 decode 空白）。
  - **按设备选档**：打开瞬间用 `isMobile()`（`navigator.userAgentData.mobile` 优先，回退 UA 嗅探）采样一次——手机拉 `-m` 中图（≤2400，移动端解码/流量小 ~4×），桌面/平板拉原图。缩略图始终是占位图。
  - **缩放**：`wheelToZoom: true` + `maxZoomLevel: 'full'`（滚轮 / 双击 / 双指捏合，PhotoSwipe 核心，无需插件）。
  - **导航**：`arrowKeys` / `escKey` / `pinchToClose` / 触屏左右滑动（核心能力）。
  - **内存上限**：`preload: [1, 1]`，最多常驻 ~3 张（1 前 + 当前 + 1 后），匹配手机解码预算。
  - PhotoSwipe Core 懒加载为独立 chunk，画廊页首屏包体保持轻量。
  - React↔PhotoSwipe 桥接有三个反馈环（`isOpenRef` / `lastIndexRef` / close handler），均加守护避免重复开/回调抖动；最新回调经 ref 始终取到最新父组件 props。
  - 设计取舍见 `docs/adr/0001-medium-tier-for-mobile-lightbox.md`（ADR 0001）。

### 影集内容层（`src/lib/albums.ts`）

- **自包含**：刻意不复用 `src/lib/markdown.ts`（posts/flows/notes/books 机制）。一个影集 = `content/albums/<slug>/` 下的 `index.mdx`（frontmatter + 正文游记）+ `manifest.json`。
- **Zod 校验 + 严格构建**：frontmatter 与 manifest 非法均在构建期 `throw`（与全站 strict-build 一致）。`medium` 字段必填——旧影集须重新生成，否则 Zod 解析构建期失败。
- manifest 路径相对资源根，构建期由 `resolveAsset()` + resourceBase 拼成绝对 URL；无 manifest 的影集仅渲染正文、无画廊。
- 导出 `getAllAlbums()` / `getAlbumBySlug()`，模块级缓存（同 markdown.ts 家族的开发态缓存坑：内容编辑后须重启 `bun dev`）。

### 预处理脚本契约（`scripts/process-album.ts`）

```
bun scripts/process-album.ts <input-dir> <slug> [--prune] [--dry-run]
```

输入一个本地原图文件夹，步骤：

1. 准备原图：HEIC → gain-map JPEG（`heic2uhdr.swift`，q95）；非 HEIC 原样拷贝。
2. 对原图写 EXIF 版权标记。
3. 算 content-hash，命名 `<stem>-<hash>.<ext>`，按需上传原件到 R2 的 `albums/<slug>/` 前缀（已存在则跳过，幂等）。
4. 生成 `-s` 缩略图（≤800，q80）→ 写 EXIF → hash → `<stem>-s-<hash>.jpg` → 上传。
5. 生成 `-m` 中图（≤2400，q90，HDR 保真）→ EXIF → hash → `<stem>-m-<hash>.jpg` → 上传。最长边已 ≤2400 则跳过（`medium == src`）。
6. 写 `manifest.json`（每图 `src` / `w` / `h` / `thumb` / `medium`）到 `content/albums/<slug>/`；若无 `index.mdx` 则生成带 frontmatter 的桩文件待编辑。
7. `--prune`：删除该 slug 下未被 manifest 引用的 R2 孤儿对象。

环境（`.env`，不入 git）：`R2_ACCOUNT_ID` / `R2_ACCESS_KEY_ID` / `R2_SECRET_ACCESS_KEY`（必填）；`R2_BUCKET`（默认为你的桶名）。外部工具：`exiftool`（`brew install exiftool`）、`swift`（Xcode CLT 自带）。`--dry-run` 跳过上传但仍跑本地转换并预览 manifest。

### 发布流程

- **文字 / MDX / manifest**：`git push main` → Cloudflare Pages 自动 `bun install --frozen-lockfile && bun run build` → 部署（自定义域 `blog.satd.tech`）。生产环境变量须设 `NEXT_PUBLIC_RESOURCE_BASE=https://blog-res.satd.tech`。
- **图片**：本地跑 `process-album.ts` 上传 R2（独立动作，**须先于对应 MDX 的 push**）。
- **顺序约定**：**先跑脚本（传图 + 写 manifest）→ 再 push MDX**。

> 备选部署：框架另附 `scripts/deploy.ts`（rsync→自建 nginx，`sshpass`，自动 reload）与 `nginx.conf.example`（含 sendfile / 文件描述符缓存 / gzip / HSTS / 分层缓存 / 去 trailing slash 重定向 / TLS 加固）。静态导出设计本身与托管方无关，任意静态服务器可托管。

## 需要人工配合操作的内容，输出 handoff.md 文件。

这是一座会慢慢长大的花园。