「一橋桐子の犯罪日記」についての感想と終活の話
感想 最近SSJの読書部で終活応援の本「一橋桐子の犯罪日記」を読みました。 桐子さんの老後生活の辛いさを感じました、お金の問題とか、人との関係とか、親の介護とか、部屋を借りるなら保証会社も難しくそうです、年を増えていくかクビになるかも知れま

笑疯了。

现在一堆人（大部分是国人），用着 openclaw 给 openclaw 疯狂提交 PR，被关闭率奇高，可能有百分之八九十，开源要完蛋了吗？

读到这篇文章，还挺有意思的。

智能体软件工程 #2 ｜重新思考 Code Review
https://mp.weixin.qq.com/s/-1GCCx1oN1FTJuHOnnFuvQ

懐かしのバブル時代
バブル時代の歌はとても個性がはっきりしています、今のJpopと雰囲気は全然違います、バブル時代の歌は明るくて、未来にワクワクする。 ３０代の私にとっても、どこか懐かしくて憧れます。 Won't Be Long -The Bubble Gum

【スピーチ】僕の2016年
2016年、僕は卒業一年目になりました、僕にとって は楽しい事もある、迷う事もある。 まずは楽しいことを話します、2016年の写真を振り替えて見ました、久（ひさ）しぶりに雪をはじめの一年だった、その一年は大学の友たちと一緒に南京の郊外（こう

周末用 Codex 重写了下 https://intokyo.net
欢迎使用。

今天看到了 Claude Code 开发者 Thariq 分享了一个他自己经常在使用的 AI 编程 Prompt，感觉这个思路可以借鉴试试。

做法其实也很简单：就是让 AI 在实现功能的同时，持续维护一份 implementation-notes 文件。以下是 Prompt：

实现 <SPEC>。（这里替换为你需要实现的功能） 

在实现过程中，请持续维护一份 implementation-notes.html 文件，记录所有我应该知道的信息，尤其是实现过程中对规范的解释、补充或偏离，包括：

- 设计决策：当规范存在模糊之处时，你做出的选择

- 偏离点：你有意没有完全按照规范实现的地方，以及原因

- 权衡取舍：你考虑过哪些替代方案，以及为什么最终选择当前方案

- 开放问题：任何你希望我确认或重新修改的内容

#AI #Claude

https://x.com/trq212/status/2056415973125796184

分享一下我们现在如何运营一家 AI-native 公司：

1. 所有的文件都存在 github 上的 organization 账号下。每接一个客户，新开一个 repo，客户之间做到隔离；

2. 内部写了一套工具，可以支撑多个客户，因为暂时是项目制，所以这套工具暂时只有内部使用。如果后期业务起来，可能会做成一套 SaaS 工具，对外服务；

3. 这套工具是受 CareerOS 这个项目启发写的，原先也写过一些，但看了 CareerOS 的框架之后，就迅速学习了。好处是，每一个新项目都能快速启动，而且能沿用一套标准，大大提高效率；

4. 向非技术的同事科普了 Claude code + codex + github，这样一来，可以方便地使用 github 同步所有文件。哪怕不会用 GitHub，也可以让 claude / codex 代劳。

5. 对接客户的时候，也会请他们授权 google drive 给我们，这样可以用 rclone 读取所有的授权数据。迅速建立起一个知识库。比如我们给客户看的 deck 和他们的视觉设计保持一致，客户大为震惊，其实我们不过是读取了他们的 vi pdf，然后抽取出一个 global.css + design token，然后加以复用；

6. 服务客户时，所有的数据，操作步骤都记录在 repo 里，哪怕是非代码层面的数据，这样即使出了问题，也可以用 AI 来分析，从而回滚或者修复；

7. 帮非技术的同事写了不少小工具，方便他们在 claude / codex 里直接调用，提高他们的效率。

最近准备主要研究下 Bub 这个 Agent 框架，小巧插件化的设计，适合研究。
它这个上下文管理的概念，有点绕，看了似懂非懂。

https://mp.weixin.qq.com/s/qkw2YG0nIS7FGklG1hHTxg

从 Go 转向 Rust 时，团队真正会遇到的取舍。

Matthias Endler 一开始就把范围限定在后端服务：Go 本来就在这个领域很强，有小型静态二进制、成熟的网络标准库，也有 HTTP、gRPC、数据库等常用生态。因此迁移到 Rust 并不是简单比较“谁更快”，而是看团队是否需要更多编译期保证、更少运行时意外，以及更强的代码约束。

Endler 对 Go 并不完全认同，但也承认 Go 在实际工程里很成功。Go 的工具链简单统一，go build、go test、gofmt 已经给开发者提供了顺手的日常体验。Rust 的 cargo 走的是相近路线，并进一步把构建、测试、格式化、文档、lint、依赖管理等能力整合得更完整。两门语言在工程体验上并不是完全对立的，差别更多落在“哪些问题交给程序员自觉处理，哪些问题交给编译器提前拦住”。

文章反复提到的一个变化，是 Rust 会把许多 Go 里依赖约定、工具或运行时检测的问题，前移到类型系统里。Go 里常见的 nil 检查、if err != nil、go test -race、sync.Mutex 使用规范，在 Rust 中分别对应 Option<T>、Result<T, E>、Send / Sync、所有权和借用规则。这样做的代价是学习曲线更陡、编译时间更长。好处是很多空指针、数据竞争和遗漏错误处理的路径，在代码运行前就会暴露出来。

Endler 也没有把 Rust 写成无条件更好的选择。Go 的并发模型仍然是它非常强的地方：一个 go 关键字就能启动 goroutine，顺序代码和并发代码没有明显语法分裂，这种日常开发顺滑感是 Rust async / await 很难完全替代的。Rust 的异步更明确，也更容易被编译器检查，但需要面对 executor、.await、Send / Sync 边界等额外概念。

真正适合迁移的，通常不是所有 Go 服务，而是那些对可靠性、尾延迟、资源占用或并发安全要求更高的部分。Endler 建议不要一次性重写整个系统，可以先拆出高 CPU、高延迟、故障频繁的服务，也可以从 worker、队列消费、数据摄取管道这类边界清楚的模块开始。保留原有 API 合同，让调用方感知不到语言变化，再通过网关或独立服务逐步切换流量，会比大规模推倒重来稳妥得多。

Go 仍然适合 Kubernetes 相关工具、CLI、开发工具、薄 API 层和胶水服务。Rust 更适合那些基础性、关键性、故障代价高的服务。Endler 给出的判断：迁移的目的不是证明某门语言赢了，而是把不同问题放到更合适的技术栈里。对很多团队来说，Go 负责简单稳定的业务服务，Rust 负责高可靠、高性能的关键路径，会是一种更自然的后端组合。

#Go #Rust

https://corrode.dev/learn/migration-guides/go-to-rust/

Remix3 去掉了 ReactJS，改成了 Model-First Development，有点意思啊🤔。
https://github.com/remix-run/remix

个人的护城河在哪里？通过开源或者个人项目来经营个人影响力是更好的选择。
https://mp.weixin.qq.com/s/SWbe-ZYDpti6UYyiZPpLvg?scene=334

所以你的 Special knowledge 是什么，品味是什么？
https://mp.weixin.qq.com/s/rsQuFcIlb0ya8Uu9oj0zdA

❓还以为是中文，没想到日文中也有「日日是好日」

受到 hayashi 影响，最近沉迷七十年代的 JPop，然后 Vibe 了一个电台。
https://jpop.czq.me/

前 OpenAI 政策负责人 Aaron Brethorst 把软件开发重新放回一个更朴素的问题：难的并不只是写代码，而是先在脑子里建立一套能运转的业务模型。

做薪资系统，要懂扣缴、税前扣除、计薪周期跨越费率变化时该怎么处理；做公交应用，要懂 GTFS feed、trip 和 route 的区别，也要知道一辆“准点”的车为什么仍然可能给出错误判断。代码只是把这些理解写下来，真正费力的部分，是先把事情理解清楚。

Agentic AI 改变的是这层关系。过去，软件行业默认一个人必须先理解业务，再把理解翻译成代码。现在，工具可以在使用者还没有建立完整领域模型时，就生成能运行的软件。于是问题不再只是“能不能做出来”，而变成了“你能不能判断它做得对不对”。

Brethorst 用两类人做了对比。一个是没有软件背景的领域专家，比如物流调度员、临床编码员、精算师。他们未必会读堆栈信息，也说不清 hash map 和 list 的差别，但他们能一眼看出某个排班违法、某组理赔编码不可能通过，因为这些输入和输出就是他们多年工作的日常。Agent 补上了他们缺少的代码生产能力，而他们提供的是工具没有的现实校验能力。

另一类是能力很强的通用工程师。他们懂架构、可靠性、测试，也能让系统稳定运行到凌晨 2 点。但进入临床编码这类陌生领域时，他们可能分不清一个看似合理的结果到底是对是错。Agent 可以生成能编译、能通过测试、却在业务上代价很高的错误规则。工程师能判断软件是否做得稳，却未必能判断结果是否正确，因为这里的正确性由领域知识决定。

在 AI 智能体出现之前，工程师还有一条路：花时间跟领域专家学习，读规范，在生产环境里踩坑，慢慢把业务模型补起来。领域专家却很难反过来补齐多年软件工程训练。现在，被工具压低成本的是把模型变成代码的那部分，不是知道“什么才是对”的那部分。领域知识没有被替代，反而更像一道护城河。

所以更有价值的人，是同时具备两层判断力的人。他既能看出生成的代码是否可靠，也能知道输出是否符合真实业务。他能写出“司机不能超过 11 小时工时”这样的测试，也知道这个测试为什么有意义。

对有经验的工程师来说，接下来要补的未必是又一个框架，而是一门真实行业、一套监管规则、一个物理流程，或任何一个需要长期浸泡才能理解的领域。Agent 可以帮人写代码，但它不能替人拥有这种经过验证的判断。

#AI #思考

https://www.brethorsting.com/blog/2026/05/domain-expertise-has-always-been-the-real-moat/

Mauro Bieg 把今天 AI 对程序员工作的影响，放到前端开发过去十多年的变化中一起看。

他觉得，很多前端开发者面对 AI 时产生的熟悉感，并不是偶然的。前端曾经是一项很专业的工作，需要理解语义化 HTML、CSS、浏览器差异、可访问性、渐进增强、Web 性能、界面设计和用户测试。

后来，框架和工具把浏览器越来越多地变成“编译目标”，很多细节被封装起来，企业也因此更容易让通用型程序员接手前端工作。

Bieg 把这个过程称为“deskilling”，也就是技术引入后，原本需要长期训练的技能被工具和流程稀释。AI 现在对编程做的事，与 JavaScript 框架曾经对前端做的事很相似：它降低了进入门槛，也提升了一些场景下的效率，但同时会削弱熟练劳动者的议价能力。对很多程序员来说，难受之处不只是岗位可能变化，还在于自己花了多年打磨的手艺，开始不再被市场同等重视。

Bieg 也承认，可以换一个角度看这件事：新工具是在提高抽象层级，让人少写一些底层代码，把注意力放到更大的问题上。工程师本来就喜欢自动化，问题在于，哪些细节可以被放下，并不是一个无关紧要的决定。前端框架隐藏了很多浏览器、性能和可访问性问题，但这些问题并不会消失；智能体写代码也类似，它不像编译器那样确定，同样的需求因为提示词或模型差异，可能得到很不一样的结果。

他把 LLM 的使用类比为过去从 Google 和 Stack Overflow 找答案。那时程序员学会用关键词找到帖子，再把答案复制到项目里，很多时候确实能跑起来。LLM 只是把这种趋势推进了一步：懂的人会更快，不懂的人也能做出一些“看起来能用”的东西。但抽象迟早会露出缝隙，到那时，仍然需要有人认真读懂生成的代码，理解它怎样嵌进现有系统，并负责修好它。

Bieg 后半部分借 Bauhaus 运动谈软件行业该怎样面对这种变化。工业化没有让好设计消失，文字处理软件也没有让排版和图形设计消失。

同样，AI 会制造更多粗糙代码和低质量内容，但这并不意味着熟悉材料、关心用户、愿意把事情做对的人就不再重要。快速原型和 MVP 有它们的价值，尤其在还没验证产品方向的时候；可一旦要长期维护，就需要知道自己做了哪些取舍，哪些该买服务，哪些该用开源库，哪些可以交给 LLM，哪些必须自己写。

等热潮过去，AI 大概会被看作工具箱里又一个工具。在那之前，行业还会经历很多难看的代码、混乱的协作，以及打着 AI 旗号发生的裁员。

#AI #软件开发

https://mastrojs.github.io/blog/2026-05-23-is-AI-causing-a-repeat-of-frontends-lost-decade/