记录一下最近遇到的一个糟心事儿。
最近两个月开始又开始找工作机会，总的来说很不顺利，托朋友联系了两个内推也是石沉大海。（各位要是有远程工作的机会也请联系 [email protected] ）
昨天在 Linkedin 上有个 web3 背景的猎头联系我说有个不错的 contract 工作，就是需要先完成一个 code assessment。这个测试放在 notion 上，指向一个 github repo。但实际上，只要你在本地运行
这个攻击手法相当低劣，低级且恶劣，低级到了随手搜一下
各位都小心一点，不要在本地运行任何来历不明的代码。即使源码里没有搜出可疑的内容也并不可靠，完全可以把攻击代码放在第三方依赖里。vscode 用户可以使用 devcontainer 来执行这些临时项目，能极大的缓解威胁。
最近两个月开始又开始找工作机会，总的来说很不顺利，托朋友联系了两个内推也是石沉大海。（各位要是有远程工作的机会也请联系 [email protected] ）
昨天在 Linkedin 上有个 web3 背景的猎头联系我说有个不错的 contract 工作，就是需要先完成一个 code assessment。这个测试放在 notion 上，指向一个 github repo。但实际上，只要你在本地运行
npm start，就会启动恶意脚本，偷偷下载一个 js 脚本并执行。这个攻击手法相当低劣，低级且恶劣，低级到了随手搜一下
eval 就能发现。各位都小心一点，不要在本地运行任何来历不明的代码。即使源码里没有搜出可疑的内容也并不可靠，完全可以把攻击代码放在第三方依赖里。vscode 用户可以使用 devcontainer 来执行这些临时项目，能极大的缓解威胁。
作为一个从业十多年的程序员，我已经半年没手写过一行代码了。上个月大概提交了 20 万行，这个月大概 4 万行。
昨天认真考虑了一下这个现象，我个人认为，虽然 AI 仍然存在显然的不足与缺陷，在非主流领域的代码水平不高甚至有些低劣，但是程序员确实不应该再执着于手写代码和 review 了，自动化、工业化的星辰大海就在眼前，有太多值得探索和尝试的领域。
• 不要再自视优越地吐槽 AI 代码质量差，而是应该探索如何生成高质量的代码。
• 不要再抱怨 AI 代码太多 review 不过来，而是应该探索工业规模的测试和 review 方案。
我认为从 opus-4.7/gpt-5.4 开始，AI 的能力到达了一个分水岭，它能够在严格的约束下，完成它本身并不擅长和理解的工作。可以称之为 harness，不过我不喜欢使用这些转瞬即逝的 fancy words。
软件工程师，作为一个工程师，关注的应该是在限定的资源和时间内，找出和解决问题的能力。对工具本身的钻研，应该服务于解决问题这个根本目标。软件工程会越来越回归一个真实世界的“社会工程问题”，人类拥有上下文难以描述的隐知识，如真实需求、组织结构、资源限制等等，人类用自己的隐知识去驾驭工业化的生产结构，这才是未来的探索之路。
Ps. 目前看来，AI 并不能替换生产者，它只能作为生产者的工具发挥增效。这也许是个好消息，也许是个坏消息，而且不一定对。
昨天认真考虑了一下这个现象，我个人认为，虽然 AI 仍然存在显然的不足与缺陷，在非主流领域的代码水平不高甚至有些低劣，但是程序员确实不应该再执着于手写代码和 review 了，自动化、工业化的星辰大海就在眼前，有太多值得探索和尝试的领域。
• 不要再自视优越地吐槽 AI 代码质量差，而是应该探索如何生成高质量的代码。
• 不要再抱怨 AI 代码太多 review 不过来，而是应该探索工业规模的测试和 review 方案。
我认为从 opus-4.7/gpt-5.4 开始，AI 的能力到达了一个分水岭，它能够在严格的约束下，完成它本身并不擅长和理解的工作。可以称之为 harness，不过我不喜欢使用这些转瞬即逝的 fancy words。
软件工程师，作为一个工程师，关注的应该是在限定的资源和时间内，找出和解决问题的能力。对工具本身的钻研，应该服务于解决问题这个根本目标。软件工程会越来越回归一个真实世界的“社会工程问题”，人类拥有上下文难以描述的隐知识，如真实需求、组织结构、资源限制等等，人类用自己的隐知识去驾驭工业化的生产结构，这才是未来的探索之路。
Ps. 目前看来，AI 并不能替换生产者，它只能作为生产者的工具发挥增效。这也许是个好消息，也许是个坏消息，而且不一定对。
https://www.notion.so/laisky/GitHub-RCE-Vulnerability-CVE-2026-3854-Breakdown-Wiz-Blog-352ba4011a8681c3afdfe340d1a76fd5?source=copy_link
上周看到这个号称仅用 git push 就实现了对 GitHub 服务器的远程控制。这篇文章介绍了攻击原理，没想到实际上这么草台。
网关服务 babeld 接收用户请求，进行身份验证后，就会设置
这么重要的内部权限字段，居然接受明文的用户输入。这种低级错误应该连 GitHub 免费提供的 CodeQL 都能扫出来，太不应该了。
上周看到这个号称仅用 git push 就实现了对 GitHub 服务器的远程控制。这篇文章介绍了攻击原理，没想到实际上这么草台。
网关服务 babeld 接收用户请求，进行身份验证后，就会设置
X-Stat header 作为内部服务通信的关键权限信息。然而，X-Stat 作为重要的内部属性，居然允许直接拼接外部的用户输入，而且在拼接时没有进行 sanitize 处理，导致攻击者可以简单的使用 ; 来实现任意注入。这么重要的内部权限字段，居然接受明文的用户输入。这种低级错误应该连 GitHub 免费提供的 CodeQL 都能扫出来，太不应该了。
laisky on Notion
GitHub RCE Vulnerability: CVE-2026-3854 Breakdown | Wiz Blog | Notion
Wiz Research uncovered a critical vulnerability (CVE-2026-3854) in GitHub's internal git infrastructure that could have affected both GitHub.com and GitHub Enterprise Server. By exploiting an injection flaw in GitHub's internal protocol, any authenticated…
https://laisky.notion.site/VMware-e1000-vmxnet3-34cba4011a8680ea9242e1f93d990b17?source=copy_link
一个小笔记。我家里用一台 windows 11 主机，通过 vmware workstation pro 运行了一些虚拟机，然后通过 tailscale 和我的其他 VPS 打通。
近期某些虚拟机在网络流量较大时会出现网络中断，表现为一个 CPU 完全跑满，外网延迟增加到 15s 以上，重启 tailscale 后能够恢复。
让 codex app 去帮我修复，它将 e1000 网卡修改为了 vmxnet3，目前已经用了一周左右，很稳定，没有再出现问题。整个故障的排查、修复和记笔记都是 codex app 完成的，不得不说 codex app 完美解决了我不懂也不想折腾 windows 的局限😂。
一个小笔记。我家里用一台 windows 11 主机，通过 vmware workstation pro 运行了一些虚拟机，然后通过 tailscale 和我的其他 VPS 打通。
近期某些虚拟机在网络流量较大时会出现网络中断，表现为一个 CPU 完全跑满，外网延迟增加到 15s 以上，重启 tailscale 后能够恢复。
让 codex app 去帮我修复，它将 e1000 网卡修改为了 vmxnet3，目前已经用了一周左右，很稳定，没有再出现问题。整个故障的排查、修复和记笔记都是 codex app 完成的，不得不说 codex app 完美解决了我不懂也不想折腾 windows 的局限😂。
laisky on Notion
VMware 虚拟机网卡从 e1000 迁移到 vmxnet3 操作手册 | Notion
简单分享下我是怎么花最少的钱，但是又非常重度、高频的依赖 AI coding 的。
我目前的订阅是，最便宜的 copilot 和 codex。这两个的特点在于：codex 是按量付费的，而 copilot 是按次付费的。这个区别是最关键的，如果你更喜欢 cc，那么你可以把本文中的 codex 替换为 cc，一样的逻辑。
而作为 coding，其实工作可以拆分为两大类型，我相信其他大部分文字工作也可以这么拆分：
1. 计划阶段：此时会涉及非常高频交流，但是每次交流的内容都不多，你可以使用 codex 的最高思考模式，写下最核心的关键逻辑
2. 实施阶段：这是广义的实施，包括收集资料、撰写文档、coding、testing、debug 反复调试 都可以视为实施。
copilot 的按次付费，使它成为实施阶段的最佳性价比选择。发送一次 prompt 算一次费用，只要 agent loop 没有结束，期间一切的 tools 调用都不计费。只要通过 prompt 给它输入我们之前和 codex 聊好的 spec，接下来就让 copilot 吭哧吭哧的去把最脏最累但是没有特别高思考难度的活全部干完。
⚠️很可惜，copilot 已经取消了按次计费，而且设置了严格的基于用量的 limit，黄金时代结束了。
具体怎么让 copilot（我最爱用 gpt-5.4） 能够不中断的，一次性干完最多活，这里面需要调试 copilot 的 instructions，具体就不展开了，各有各的方法。但是我这里推荐一下我的 remote MCP server https://mcp.laisky.com/tools/get_user_requests
其中的这个 get_user_requests tool，相当于是在 MCP 上维护了一个 TODO list，而且是你可以动态编辑的 TODO list。你只需要在 instructions 里要求 copilot 频繁的，在每次子任务结束后，都去调用 get_user_requests，而且必须在连续两次调用 get_user_requests 为空后才能返回。你其实就拥有了在不打断 agent 一次任务的前提下，和 agent 沟通的能力，而利用这个能力，你就可以让 copilot 在一次计费里，干掉尽可能多的活。
举个我的例子，极端情况下，我很可能一天只需要跑 3 次 copilot，中间会停两次是因为我要吃午饭和晚饭，没精力去盯着 get_user_requests 的 requests queue 了。我甚至经常跑出 copilot 的 tokens quota limit，会被停用一段时间，估计很多人可能都不知道 copilot 还有limit 吧😂
Copilot 还有个我非常喜欢的地方是，如果你把配额用超了，它可以自动转为按次计费，每一次请求约为 $0.03 USD，很实惠。
如果你非常有钱，或者公司给无限的订阅资金，可以忽略这一条。和穷人们共勉。
我目前的订阅是，最便宜的 copilot 和 codex。这两个的特点在于：codex 是按量付费的，而 copilot 是按次付费的。这个区别是最关键的，如果你更喜欢 cc，那么你可以把本文中的 codex 替换为 cc，一样的逻辑。
而作为 coding，其实工作可以拆分为两大类型，我相信其他大部分文字工作也可以这么拆分：
1. 计划阶段：此时会涉及非常高频交流，但是每次交流的内容都不多，你可以使用 codex 的最高思考模式，写下最核心的关键逻辑
2. 实施阶段：这是广义的实施，包括收集资料、撰写文档、coding、testing、debug 反复调试 都可以视为实施。
⚠️很可惜，copilot 已经取消了按次计费，而且设置了严格的基于用量的 limit，黄金时代结束了。
具体怎么让 copilot（我最爱用 gpt-5.4） 能够不中断的，一次性干完最多活，这里面需要调试 copilot 的 instructions，具体就不展开了，各有各的方法。但是我这里推荐一下我的 remote MCP server https://mcp.laisky.com/tools/get_user_requests
其中的这个 get_user_requests tool，相当于是在 MCP 上维护了一个 TODO list，而且是你可以动态编辑的 TODO list。你只需要在 instructions 里要求 copilot 频繁的，在每次子任务结束后，都去调用 get_user_requests，而且必须在连续两次调用 get_user_requests 为空后才能返回。你其实就拥有了在不打断 agent 一次任务的前提下，和 agent 沟通的能力，而利用这个能力，你就可以让 copilot 在一次计费里，干掉尽可能多的活。
举个我的例子，极端情况下，我很可能一天只需要跑 3 次 copilot，中间会停两次是因为我要吃午饭和晚饭，没精力去盯着 get_user_requests 的 requests queue 了。我甚至经常跑出 copilot 的 tokens quota limit，会被停用一段时间，估计很多人可能都不知道 copilot 还有limit 吧😂
Copilot 还有个我非常喜欢的地方是，如果你把配额用超了，它可以自动转为按次计费，每一次请求约为 $0.03 USD，很实惠。
如果你非常有钱，或者公司给无限的订阅资金，可以忽略这一条。和穷人们共勉。
https://developer.1password.com/docs/service-accounts/use-with-1password-cli/
最近折腾的一件事就是把服务器部署的密钥全部用 1Password 管理了。
以前的做法比较粗糙，我有一个 private github repo 专门存放各种密钥，每台主机上都在固定的位置 clone 这个 repo。
现在我在 1Password 上创建了一个 vault 专门存放这些密钥，然后为每一台主机创建一个 service account，给它访问这个 vault 的权限。每台主机上安装 1Password CLI，并使用对应的 service account 登录，就可以用下面的形式定义密钥了。
对于那些通过环境变量获得密钥的应用，直接使用
如果你不喜欢环境变量，也可以通过 1Password 的 SDK 在代码里直接获取密钥值。
这样做的优点是，可以在 1pwd 的网站上通过吊销 service account 的访问权限来快速撤销某台主机的密钥访问。可惜就是 audit log 仅对 Business 版本可用，还有就是 service account 的权限粒度仅支持 vault 级别，聊胜于无吧，对于个人服务来说至少比裸奔强多了。
最近折腾的一件事就是把服务器部署的密钥全部用 1Password 管理了。
以前的做法比较粗糙，我有一个 private github repo 专门存放各种密钥，每台主机上都在固定的位置 clone 这个 repo。
现在我在 1Password 上创建了一个 vault 专门存放这些密钥，然后为每一台主机创建一个 service account，给它访问这个 vault 的权限。每台主机上安装 1Password CLI，并使用对应的 service account 登录，就可以用下面的形式定义密钥了。
SESSION_SECRET=op://configs/oneapi/SESSION_SECRET
SQL_DSN=op://configs/oneapi/SQL_DSN
LOG_PUSH_TOKEN=op://configs/oneapi/LOG_PUSH_TOKEN对于那些通过环境变量获得密钥的应用，直接使用
op run --env-file=./one-api/b1.env -- <ORIGINAL_COMMAND> 就可以了，1pwd cli 会自动解析这些环境变量并替换成对应的密钥值。如果你不喜欢环境变量，也可以通过 1Password 的 SDK 在代码里直接获取密钥值。
这样做的优点是，可以在 1pwd 的网站上通过吊销 service account 的访问权限来快速撤销某台主机的密钥访问。可惜就是 audit log 仅对 Business 版本可用，还有就是 service account 的权限粒度仅支持 vault 级别，聊胜于无吧，对于个人服务来说至少比裸奔强多了。
1Password Developer
Use service accounts with 1Password CLI - 1Password Developer
Learn how to use service accounts with 1Password CLI.
https://laisky.notion.site/Effective-context-engineering-for-AI-agents-Anthropic-2ddba4011a868170ac2ddd9017afadde?source=copy_link
Anthropic 介绍 context engineering 的文章。
- prompt engineering 主要关注如何撰写 system prompt。
- context engineering 则关注 agent 相关的所有工程问题。
注意力是稀缺的，context 过长，反而会导致模型能力下降（context rot）。
所谓 Agent，就是在 loop 内自动调用工具的 LLM。
context 注入的两种方式：
1. 在推理前，利用 RAG 检索和注入 context（延迟低）
2. 在 Agent 运行的过程中，通过 tools 自动检索和读取（可以 progressive disclosure，信息更准确）。推荐使用类文件系统的信息索引方式，这些文件的路径本身，也包含重要的信息。
long-horizon tasks 的 context 优化工具箱：
- compaction：压缩 context，仅保留关键信息。记忆信息拆分不同的 TTL 层级，然后按照不同的文件路径进行组织和存储。
- structured note-taking：context 外部的记忆工具，如 TODO list
- multi-agent architectures：拆分子任务，coordinator 仅派发任务和接收 sub-agent worker 的摘要。不要试图用一个上下文维护大型项目的全部信息。
Anthropic 还有一篇 Effective harnesses for long-running agents 感觉只是对本文的 multi-agent architectures 的一些实践小经验总结，信息量不多。
👆 prev
Anthropic 介绍 context engineering 的文章。
- prompt engineering 主要关注如何撰写 system prompt。
- context engineering 则关注 agent 相关的所有工程问题。
注意力是稀缺的，context 过长，反而会导致模型能力下降（context rot）。
所谓 Agent，就是在 loop 内自动调用工具的 LLM。
context 注入的两种方式：
1. 在推理前，利用 RAG 检索和注入 context（延迟低）
2. 在 Agent 运行的过程中，通过 tools 自动检索和读取（可以 progressive disclosure，信息更准确）。推荐使用类文件系统的信息索引方式，这些文件的路径本身，也包含重要的信息。
long-horizon tasks 的 context 优化工具箱：
- compaction：压缩 context，仅保留关键信息。记忆信息拆分不同的 TTL 层级，然后按照不同的文件路径进行组织和存储。
- structured note-taking：context 外部的记忆工具，如 TODO list
- multi-agent architectures：拆分子任务，coordinator 仅派发任务和接收 sub-agent worker 的摘要。不要试图用一个上下文维护大型项目的全部信息。
Anthropic 还有一篇 Effective harnesses for long-running agents 感觉只是对本文的 multi-agent architectures 的一些实践小经验总结，信息量不多。
👆 prev
laisky on Notion
Effective context engineering for AI agents \ Anthropic | Notion
Context is a critical but finite resource for AI agents. In this post, we explore strategies for effectively curating and managing the context that powers them.
