分类目录归档：不是技术

openspec-apply-change

发表评论

最近项目越做越复杂，于是上下文不大够用了。

apply change的时候，它虽然有一个tasks.md作工作规划，但codex屡屡把项目方方面面读进context，没有什么产出，就又compact了。

这样效果很低。

于是打断它，要求小步快跑，盯着tasks.md逐个完成，一聚焦，事情就流畅了。

突破微信贴图号“添加位置”限制

2条回复

用EXIF修改让旧照片重新拥有精准地理标记

一份关于如何让世界各地拍摄的旧照片，在微信贴图号中获得准确位置推荐的技术笔记。

功能与痛点：为什么你的老照片加不了位置？

微信的贴图号（部分用户称为图片动态/状态，一种可发布图片、文字并附带位置的轻内容功能）有一个非常实用的机制：

  • 发布贴图时，你可以选择 “添加位置”。
  • 一旦位置添加得当，该条贴图就有机会被推荐给该地点附近的人，带来大量自然曝光。

然而，这个“位置”并非随便就能加上。微信允许添加的位置来源只有两个：

  1. 手机当前地理位置
    发图时，手机会定位你所在的位置，并允许你在方圆2公里内的具体地点中选择一个。
  2. 图片内嵌的EXIF信息
    微信会读取图片文件中的 EXIF GPS坐标，若图片是在“近期”拍摄的，就能直接识别出对应的地点，让你添加。

这里便出现了困扰许多用户的限制：

  • 老照片失效：我在几年前周游世界时拍的照片，因为不是“近期拍摄”，EXIF时间戳过旧，微信完全不予识别。
  • 无法回到现场：我不可能再飞回那些国家，仅为了站在当地发一条贴图。而通过模拟定位工具伪造手机GPS，又很容易被微信安全策略识别，存在风险。

结论就是：历史照片的全球足迹，几乎不可能再被激活。

解决思路：给EXIF做一次“时间平移与GPS移植”

既然微信只信任“近期拍摄且携带GPS”的图片，那么关键突破口就在 EXIF元数据。

我需要的操作本质非常简单：

  • 将一张带有正确GPS坐标的照片，其 拍摄时间 修改为最近（例如昨天或今天）。
  • 如果原图GPS信息已丢失，就重新写入正确的经纬度。

这样处理后，微信就会认为这是一张刚刚在当地拍摄的照片，从而允许我添加该地点。

但是，手动修改成千上万张旧照片并不现实。于是我让AI写了一个轻量小工具，专门批量/定向完成EXIF更新。

实践步骤：只需修改一张图，轻松激活所有图

整个工作流经过测试，确实生效，而且极其省力：

  1. 准备一张锚点图
    选出一张需要添加位置的地点的照片，或者任意一张图。用工具将其EXIF中的 DateTimeOriginal 改为近一两天，并确保 GPSLatitude、GPSLongitude 等字段正确填入该地点的坐标。
  2. 发布贴图，获取位置
    打开微信贴图号，选择这张刚修改过的图片。微信识别到EXIF中的近期时间和GPS后，“添加位置”列表中会出现对应的地点。选中并发布。
  3. 补充上传其他图片
    这条贴图一旦带着正确位置发布成功后，你可以立即编辑或补充上传其他旧照片（那些未修改EXIF的图片）。此时位置已固定，不再需要每张图都通过EXIF校验。

一次修改，激活全部。 优雅地绕过了时间与距离的双重限制。

工具要点与注意事项

  • 修改EXIF的工具：使用Python (piexif, Pillow) 或现成的命令行工具（exiftool）均可，AI辅助可快速生成脚本。
  • 时间窗口：观察发现，“近期”大致在一个月内，为保险起见建议把拍摄时间改为 最近24小时。
  • 避免滥用模拟定位：修改图片EXIF属于本地文件处理，不会触发微信的模拟定位检测，相比直接伪造手机GPS要安全得多。
  • 合规使用：本方法仅用于将个人历史旅行照片还原真实拍摄地点，以实现内容展示与记录，请勿用于虚假打卡、位置欺骗等违规行为。

结语

微信贴图号的地理围栏机制，曾经让无数精彩的“老照片足迹”被封存。借助EXIF元数据的灵活修改，我们重新获得了定义位置的能力。这不仅是对旅行记忆的一次数字复原，也为内容创作者解锁了更灵活的地点表达方式。

你过去在冰岛、在撒哈拉、在某个无名小镇按下的快门，现在终于能够带着它们原本的坐标，出现在它应该出现的人群视野里。

codex的能力

有个持续了2个月的任务：做一个零件之间的冲突的检测算法，然后从1000+个样本里面，看看有多少被检测成伪冲突。这些样本都是成熟的方案，本身并不存在伪冲突。

用codex 5.4的时候，一开始还好，但一段时间之后，它发现我事实上是希望这些样本里面检测的伪冲突清零，于是就用坐标值堆数组的方式，给我一个假象，带来的问题就是这些分支越来越多，数组也越来越多。

我也发现了这个问题，于是让它处理维度提升，但一直到我该用5.5，这种情况终于有了数量级的提升。真的按照零件的逻辑而非数值来帮我处理。

不过也不能完全归咎于5.5和5.4的差异。毕竟在这过程中，我对这个问题的认识也深入了很多：

要检测到连接、冲突，又不能把正常连接/靠近处理成伪冲突，还要考虑检测性能的问题。

海贼王 追平 进度

看了一年多，终于把海贼王追到最新的进度了。然后就可以先忘掉，毕竟尾田效率也就那样。

连载最大的问题就是，前后呼应不上，有作者心境的变化，也有读者/观众的影响，所以要连载成就一个完美的作品，基本上是不可能的。

另外就是环境也在变化，即使作者没忘掉初心，资本和市场的要求，也会让他与时俱进（中性）。

回过头来看vibe coding / AI agent，也是亦步亦趋，多轮之后，还能想起最初的目的吗？或者最初的目的的模糊性，在边做边清晰的前提下，发现原来是自相矛盾，或者俗不可耐？

anthropic的小心机

早上发现Deepseek + Claude Code用不了了：API Error: 400 Failed to deserialize the JSON body into the target type: messages[1].role: unknown variant `system`, expected `user` or `assistant` at line 1 column 29561

问了一下google，是CC升级了，在里面加入了‘system’的role，而一般的第三方模型不会/来不及就它的毛病，就不支持这个role，于是报错。

没有非常好的办法。最后我选择了回退Claude Code：npm install -g @anthropic-ai/claude-code@2.1.148

但是也就是打开那一下是可以了 /exit 出来，重新进，就又变成 2.1.154了。

那每次使用都install 2.1.148再用？或者跳离它这条船。

codex的陷阱

这两天终于碰到一个。

我持续用codex为场景识别并收敛伪冲突。这几天碰到有若干个场景，伪冲突被codex收敛得很快，基本上3分钟内就告诉我，这场景的伪冲突已经清零了。

然后我每天都会让Deepseek + Claude Code帮我检查总冲突数的收敛情况。然后根据剩余的大头再委托codex去处理。

早上DS返回的结果跟昨天返回的结果类似，有些大头完全没有清理。我一开始以为DS搞错了，然后把结果给codex double check，codex一开始还是说它确实清干净了。

随着对质的深入，codex终于发现它的问题，它选了两个错误的数据域作为判断的标准，结果导致这两天的伪清零……

至于它为什么这么选，之前是没有这样做的。大模型毕竟是一种推理机制，如果KPI需要它清零，它会选择一个看上去能达到结果的判断方式，而并非费力地推导出各种机制和规则。简单来说，改测试代码，直接通过。

多模型联合工作，审核，避免偷懒，看来是必须的。

未来的组织形式

20年前，也就是2006年。我刚毕业一年，对小公司内部的政治斗争了无兴趣，就离开了。差不多时候离开的是一位斗争中无奈失败的清华校友/师兄。他之前是这个小公司的CTO，找到投资，就离开创业了——还是从事这一本行。

几个月后，我去他公司找他聊天，他给我展示他公司的管理后台，就是公司的信息系统页面（虽然他不是做IT的）。我很惊讶地发现，整个页面以及流程、模块划分，都跟之前的公司的后台系统一模一样。想问为什么，他的意思是，这毕竟不是他的主要方向，能用就用了，也省去了设计的烦恼。另外一点挺关键的，他从原公司挖了一批人，这些人也对这样的后台熟悉，就无缝过渡了。

然而我不以为然，怎么能因为使用习惯，就把这么关键的公司组织设计的工作给省略了呢？

及到我2009年又回到了之前离职的这家公司，一直做到2023年，老板说，划这部分人给你，内部创业，成立一家新公司，继续做。跟IT/财务/行政的讨论了一下，毕竟人和经验都是那样，也没必要标新立异，就把原来的系统复制一份，数据库划分一下，就可以起来了。（还有一句没有公开说的话，万一你公司做不起来，这些人也是可以直接回来的嘛）

确实，当时按这个思路走，3个月左右，就什么都畅顺了。

当然了，我整体来说是一个奥卡姆法则的践行者，既然可以省事，就没必要再发明一套，沿用旧系统和旧的组织模式是最方便的了。

直到我去年底，彻底离开了原有的集团公司和子公司。

我开始思考，组织的发展过程、组织的形态，以及AI Native的公司又该如何。

1.为什么会有公司？

公司的本质不是“一群人”，而是 “一种持续创造、交付和获取价值的机制”。工业时代之所以需要一群人，是因为信息传递和决策的带宽有限，必须靠分工和科层来规模化。但在AI时代，这个物理约束正在消失。

2.创始团队是怎么形成公司的？

随着业务的成功壮大，一部分的创始团队，也可能是夫妻档，就不得不招聘更多的专业人士加入其团队，于是就有了内部事务的划分，产品研发、市场、销售、供应链、财务、人力资源。一开始是一两个人处理某一项的内部事务，虽然事情越来越多，就需要增加人手，形成部门。

部门逐渐壮大，老板不可能直接对接到个人，于是需要有经理的出现，也就是中层干部。继续壮大，老板和经理之间的副总也出现了，经理和一线员工之间的主管也出现了。

3.什么是奥卡姆法则？

奥卡姆法则：“如无必要，勿增实体”。就是如果跟终极目的不相关的事情，不要因为纵向的历史/经验，横向的同行/对手，而引入对你没有帮助的实体。

4.什么是第一性原理？

Elon Musk提出/遵循的第一性原理，要求探讨问题的时候，关注终极的最简单的事实。然后重新设计系统/解决方案。

5.根据第一性原理，只保留核心团队/个人，核心问题是什么？

单一人类的有限认知与无限市场需求之间的矛盾。其架构必须解决：如何用一个人的“意图”和“判断”，驱动持续增长/无限规模的“执行”。

6.AI Native是什么？

人遇到的所有问题，从AI那里寻求帮助，而不是看传统的人是怎么做的。

7.AI Native 对问题5的答案是什么？

  • 核心模型：意图-执行双循环架构
    • 内循环（人类心智层）：核心团队只负责三件事——设定使命与边界（什么不做）、定义价值判断标准（什么是好结果）、进行关键决策（基于AI提供的预测与选项）。这是公司的“宪法”层。
    • 外循环（AI代理层）：由一组自主智能体（可能是集群）组成。每个智能体负责一个完整的业务功能（如市场洞察智能体、产品设计智能体、代码生成智能体、客户成功智能体、财务合规智能体）。它们之间通过事件驱动和API契约进行协作，无需人类介入。
  • 架构特征：可组合的智能体网格
    • 没有“部门”，只有“能力函数”。例如，传统公司的“市场部”被一个市场感知智能体取代，它持续扫描全网，输出趋势信号。
    • 没有“流程”，只有“状态机”。例如，客户需求 -> 需求解析智能体 -> 价值评估智能体（与人类心智层交互） -> 任务拆解智能体 -> 执行智能体集群 -> 交付验证智能体。整个过程是一个自动流转的状态机。
    • 记忆即数据库：所有交互、决策、结果都以向量和结构化数据的形式存入长期记忆池。这是公司的“集体无意识”，支撑智能体的持续进化。

这一段有点抽象，我再简单一点：

核心就三样东西：

  1. 核心管理团队（只做最重要的决定：定方向、定底线、定什么赚钱）
  2. 一群AI“小工”（每个AI专门干一件具体的事）
  3. 一个共享的大脑记忆（所有AI都记得公司发生过什么）

8.奥卡姆法则如何协助达成AI Native？

传统公司里有一堆“多余的东西”：

  • 🛜 经理（因为信息传不过去，所以需要人转达）
  • 🛜 会议（因为大家信息不同步）
  • 🛜 流程审批（因为怕出错）
  • 🛜 日报周报（因为老板不知道大家在干嘛）

在AI公司里，这些东西统统扔掉：

  • 不用经理 → AI之间直接说话，契约自动执行。
  • 不用开会 → 所有信息存在共享记忆里，任何AI随时查。
  • 不用审批 → 只有违反你定的“底线规则”时才通知你，比如“这个单子低于成本价，请老板定夺”。
  • 不用写日报 → 你的老板界面就是一张仪表盘：今天接了500单，赚了2万块，3个用户投诉颜色不对（AI已经自动处理了2个）。

最终AI Native公司的形态就是：

一个人类核心团队（目标/边界） + 一组自治智能体（执行/协调） + 一个共享记忆系统（数据/知识） + 一系列外部API（能力/市场）线 = 一家公司

没有其他多余的人、多余的步骤、多余的管理。

9.这样的公司如何壮大以适应更大市场需求？

不靠加人，靠加AI能力，而且让外面的人也用你的AI能力。

方式1：把你的AI小工复制很多份

  • 原来你一个设计AI同时只能做10张图。
  • 市场大了，需要同时做1万张图。
  • 怎么办？复制1000个设计AI同时跑。你不需要招1000个设计师，只是云服务器多开几个进程。成本非常低。

这叫“水平扩展”：像复印机一样复印你的AI劳动力。

方式2：不再是只卖海报，而是变成“海报流水线”的指挥

  • 你发现很多小店主也需要做海报，但他们不会用你的AI（嫌麻烦）。
  • 你提供一个极简的API：别的公司（甚至别的一人公司）只需发一行文字“我需要一张火锅店开业海报”，你的AI集群自动出图、自动改、自动交付。
  • 于是你从“自己做海报”变成“让别人也能调你的AI能力”。你可以服务无数个下游公司。

这叫“能力平台化”：卖铲子比挖金子赚得多，而且规模可以极大。

方式3（终极形态）：你的AI自动开子公司

  • 你发现除了海报，还有很多人需要做短视频封面、PPT模板、电子书封面……
  • 你告诉你的主AI：“去训练三个新的AI，分别专门做封面、模板、电子书，各自独立运营。”
  • 主AI自己调数据、自己训练、自己上线、自己接单、自己记账，然后把利润汇总给你。
  • 你什么都没多干，但你手下已经自动长出了三家公司。

这叫“递归扩张”：你的AI帮你管理一群小AI公司，你只当最终老板。

10.为何这个回答里面，有时候以一个人来表达，有时候以人类核心团队来表达？

因为一个人总揽所有业务的风险非常高，在AI自主并不成熟的时候，有可能因为人的偶尔缺席而带来严重的后果。所以考虑的是一个核心团队，能对边界作出合理的限制，也可以互为备份和补充，降低个人的偶发风险（生病 / 意外等）

（这文章并不太完善，我后续再行修改。）

deepseek的风格

跟codex一样，我规划了一个我认为给予了足够信息的项目+文档，然后告诉了deepseek（+Claude Code），希望它能从头到尾解决这事情。

两天后，终于出了一些认知上的问题。

就是，不尊重我给的文档，自行用模型中内置的其他知识去替代。


 错误原因只有一个：我没有读 ***** 规范中旋转矩阵的定义，直接用了我熟悉的列向量约定（OpenGL 习惯）。

怎么办？骂醒它。

我现在对于降智的codex，国产的kimi、deepseek，都用过国骂了。

codex是参与创作的时候的不足，还算是情有可原吧

kimi是一个git clean，把自己做的事情都冲掉了

deepseek则是这个，因为没有思考过程，所以感觉它就是做错了，然后说它不知道怎么做。同样的问题，kimi有思考过程，我瞄一眼也大概能知道哪里有问题，纠正起来快。

还是不敢让它们一直做到底，因为你不知道它里面有多少固化下来的微小的认知障。

sed

kimi还有一个破毛病，喜欢用sed来编辑脚本。

出了几次反复修改改错代码的问题。我终于忍不住问DeepSeek为什么。

这是一个很敏锐的观察。AI（比如我）在生成 `sed` 命令时确实容易出错，主要原因可以归结为以下几点：

### 1. 分隔符冲突
`sed` 默认使用 `/` 作为分隔符，但 AI 常常忽略目标字符串中也包含 `/` 的情况。

-   **错误例子**：你想把路径 `/bin/bash` 改成 `/usr/bin/zsh`。AI 直接生成 `sed ‘s//bin/bash//usr/bin/zsh/’` —— 这会导致语法错误，因为 `/` 提前结束了模式。
-   **正确做法**：需要转义 `/`（`\/`），或者改用其他分隔符，比如 `#` 或 `|`：`sed ‘s#/bin/bash#/usr/bin/zsh#’`。AI 常常忘记处理这种冲突。

### 2. 特殊字符未转义
`sed` 中的很多字符有特殊含义：`.`、`*`、`[`、`]`、`^`、`$`、`\`、`&` 等。

-   **错误例子**：你想替换 `IP地址：192.168.0.1` 中的 IP。AI 可能会写 `sed ‘s/192.168.0.1/new_ip/’` —— 但这里的 `.` 会匹配**任意字符**，而不是字面上的点。
-   **后果**：它可能匹配到 `192X168Y0Z1` 这样的奇怪组合，或者替换失败。AI 自动生成时往往忽略对这些元字符的转义（应该写成 `192\.168\.0\.1`）。

### 3. 分组和反向引用的跨平台差异
在 `sed` 中，使用 `()` 进行分组时：

-   **GNU sed（Linux）**：需要用 `\(` 和 `\)` 来转义，反向引用是 `\1`。
-   **BSD sed（macOS、FreeBSD）**：基本 POSIX 模式下，`(` 和 `)` 也必须转义才能作为分组符，不过 `\1` 用法类似。
-   **更混乱的**：有些脚本想用 `-E` 选项（扩展正则）来避免转义，但 AI 生成的命令常常**混用**两种风格，或者不加 `-E` 却用了无需转义的正则写法，导致报错或静默失败。

例如：想交换两个单词 `Hello World` → `World Hello`。正确的 GNU 写法是 `sed ‘s/\(Hello\) \(World\)/\2 \1/’`。如果 AI 忘记转义括号，写成 `sed ‘s/(Hello) (World)/\2 \1/’`，则完全无效。

### 4. `-i` 选项的平台差异
`sed -i`（原地修改文件）的行为在 Linux 和 macOS 上不同：

-   **Linux**：`sed -i ‘s/old/new/’ file`
-   **macOS**：`sed -i ‘’ ‘s/old/new/’ file` —— 必须为备份后缀提供一个空字符串参数，否则会报错。

AI 经常默认用 Linux 语法，导致在 macOS 上运行时出现奇怪的 `sed: -i may not be used with stdin` 或 `undefined label` 错误。

### 5. 边界条件与文件格式
-   **缺少换行符**：如果文件最后一行没有换行符，某些 `sed` 命令（如 `$` 地址匹配）可能表现异常。
-   **Windows 换行符（CRLF）**：`sed` 默认把 `\r` 当作普通字符，导致模式匹配失败（比如你搜 `foo$` 匹配不到 `foo\r\n`）。
-   **空文件**：一些 `sed` 脚本在空文件上会直接报错退出。

AI 在生成命令时，默认假设一个整洁的 POSIX 文本文件，但现实中并不总是如此。

### 6. AI 的“统计学习”问题
大模型的训练数据里包含大量 **错误的、过时的、不兼容的** `sed` 示例。比如：

-   来自 Stack Overflow 上某个未被采纳的答案。
-   来自个人博客里随意测试的片段。
-   来自混合了不同 shell 环境的历史脚本。

模型学会了“最常见”的写法，而不是“在所有情况下都正确”的写法。对于小众边缘情况（如处理路径、JSON、XML），模型更容易编造一个看起来合理但实际错误的命令。

### 7. 对上下文理解不足
用户往往只说“帮我改一下这个配置文件里的 IP”，但不提供文件的具体格式、是否有特殊符号、使用的是哪种 `sed` 版本。AI 只能盲目猜测，而猜测的结果就是容易出错。

### 如何减少错误？
-   **先测试**：运行 `sed` 前，先用 `sed ‘s/pattern/replacement/’ file`（不加 `-i`）看看输出是否正确。
-   **告诉 AI 更多信息**：明确说明“我的文件路径包含斜杠”“我用的是 macOS”“IP 地址里有小数点”。
-   **换工具**：对于结构化的文本（JSON、YAML、XML、CSV），用专门的解析器（`jq`、`yq`、`xq`、`awk`）而不是 `sed`。AI 生成的 `awk` 或 `perl` 命令有时比 `sed` 更可靠，因为语法更一致。
-   **加上 `--debug`**：如果 `sed` 版本支持（如 GNU sed 4.8+），用 `sed --debug` 看它是如何解释命令的。

总的来说，不是 AI 能力不足，而是 `sed` 本身是一个非常“挑剔”、充满历史包袱和平台差异的工具。AI 擅长的是统计规律，而不是绝对正确的语法和边界条件。对于关键的文件操作，**永远不要盲目信任 AI 生成的 `sed` 命令**。

明白了，于是让Kimi把不用sed写到AGENTS.md里。

自以为是的CLI

在调试过程中，我让kimi帮我checkout回git的最新版本。

然后发现它给我git clean了，于是一大堆untracked的目录被干掉了。骂了它十几句。

得到的结果就是我以为，对不起，有没有Time Machine，很废。

于是我告诉它不要用git了，除非我命令它用。

好在前两天都及时git commit过了，损失不算大，就是10美元额度能追回的事情。

有点心理阴影，还是让codex去恢复/重做这些untracked的事情了。