盘古之白的间接受害者没想到是我。它和它的推崇者们就为了好看一点点，不厌其烦的，非常矫情的，没事找事的，在中文和英文及数字之间手动插入空格。数量如此之多传播之广，导致被LLM牢牢的学会了（千问）。

 

非编程的语境下，我传给LLM一个JSON列表让它帮我按照特定规则筛选数据。每个列表项目有个包含中文和数字的名称，作为标识符。

每次LLM返回给我标识符，都会非常稳定的在中文和数字中间插一个讨厌的空格，导致程序找不到列表项目。即使是用系统提示词强制它保持原样也没用，我也不想明说“不要加空格”那太丑陋了。

 

最后还是给每个列表项目赋值一个数字索引让它返回索引给我。

突然好奇一件事。平时聊天习惯一小句话就回车，几乎从来不打一大段话也不用标点符号的人，和ai交流突然不能这样做了（因为一回车ai就会开始回答不能继续输入了）。他们和ai交流会觉得难受吗？（我把这种称为短视频式说话，太常见了）

 

让gemini评价了下，它说会有两种可能：

• 被迫进化的“指令大师”： 他们开始适应，学会了先在记事本写好，或者强迫自己按下 Shift + Enter。但这时的 AI 在他们眼里不再是“聊天对象”，而是一个生产力工具。
• 逐渐沉默的“弃坑者”： 如果只是想找 AI 闲聊或者寻求情绪价值，这种输入习惯的冲突会让他们觉得“太累了，算了”，从而降低使用频率。

 

 

再发一下claude code泄露源码版本的官方包。腾讯云npm镜像的，不用担心掺了毒
https://mirrors.cloud.tencent.com/npm/@anthropic-ai/claude-code/-/@anthropic-ai/claude-code-2.1.88.tgz

 

提取源码并且可编译版本

https://github.com/andrew-kramer-inno/claude-code-source-build

买了个400包年的plus版本的token plan，确实是国产模型里面性价比非常高的一档了，5小时1500次调用每周15000次调用。最新m2.7模型跑分也非常高，据说也会开源，买个试试。

需求是让sqlalchemy在应用启动时自动建表。python后台主模块叫app（这模块名也是minimax取的），实体类定义放在models子模块里并且在__init__.py里都导入了。然后它在主初始化函数里面实现成

def create_app():
    app = Flask(__name__)
    ...
     # Import models to register them with SQLAlchemy metadata
    from app.models.dataset import Dataset, DataPreprocessingConfig
    from app.models.model import MLModel, TrainingTask, ModelDeployment
    ...

    with app.app_context():
        db.create_all()

虽然没问题但是啰嗦的要死以后还可能漏导入。我让他利用__init__.py一次性导入，它就把那堆具体的import换成import app.models，然后就出错了AttributeError: module 'app' has no attribute 'app_context'。我也傻了一开始没想明白为什么。哦原来是子模块导入当然会赋值父模块的名字到变量，覆盖掉了flask实例的app。

然后我告诉它这样报错了，它就把这行又换回最开始的那种臃肿写法了？？？最后还是手动改写成from app import models。ai写的什么屎代码，果然不能细看，公司的烂代码还是功能正常就好了不想再纠结细节了。

安卓封闭倒计时，先省略骂司马谷歌的话。原生都要等24小时的话，国产一定会顺手推舟的。本来现在装apk就非常恶心，联网上传信息对比黑名单，各种流氓管家要求扫描要求开启，要求验证码等等。下一步正好完全封锁。

https://keepandroidopen.org/zh-CN/

149版改版后，独立搜索框通过非默认搜索引擎搜索变的超级麻烦，原来点一下就行了现在要点三下，简直脑瘫。

about:config里的browser.search.widget.new改成false

https://github.com/HKUDS/OpenSpace充满了ai营销味的东西，readme里面经典的一堆emoji、ai图、浮夸文字。让gemini评价下，原汤化原食

---

通过对该项目 README 以及核心代码（特别是 openspace/skill_engine/ 目录下的相关文件）的详细阅读和事实分析，可以得出以下客观结论：

结论前置：
它宣传的“全自动进化”并非噱头，代码中确实存在一套完整且复杂的闭环机制来实现这一功能。但正如你所担忧的，随着时间推移，系统确实存在走向“臃肿和混乱”的潜在风险，尽管开发者已经在代码中硬编码了大量工程手段（如防死循环、模糊匹配、数据库追踪）来极力延缓和抑制这种风险。

以下是基于事实的代码层面的详细拆解：

一、 为什么说“全自动进化”不是噱头？

代码中真实实现了完整的“执行 -> 评估 -> 修改代码 -> 持久化”的闭环引擎，这主要体现在以下几个核心模块：

1. 评估器 (analyzer.py)：
   在 Agent 执行完任务后，ExecutionAnalyzer 会拦截执行录像，构建 Prompt 交给 LLM 进行复盘。它会输出一份 ExecutionAnalysis，指出任务中哪些环节出错、哪些工具不好用、或者发现了什么新的工作流。
2. 进化触发器 (evolver.py)：
   代码中明确定义了三种真实的进化类型（EvolutionType）：
   • FIX：原地修复。当技能出错时，直接修改原文件。
   • DERIVED：衍生。基于现有技能复制出一个新目录，并进行升级。
   • CAPTURED：捕获。从零开始，为新发现的高效模式创建一个全新的技能文件夹。
3. 实体代码修改 (patch.py)：
   这不是口头说说，引擎会真实地读写本地磁盘。支持 FULL（全量覆盖）、DIFF（局部替换）和 PATCH（多文件补丁）三种 LLM 输出格式。
4. 触发条件：除了任务后分析，代码中还实现了 TOOL_DEGRADATION（工具质量退化触发）和 METRIC_MONITOR（指标监控触发），这意味着它会在后台自动扫描并触发重构。

---

二、 会不会出现“越来越臃肿和混乱”的问题？

答案是：大概率会，但开发者做了很重的防御性编程。

基于 LLM 的不确定性，自动修改代码必然面临状态发散的问题。从源码细节来看，系统的隐患和防线并存：

1. 关于“臃肿”的风险与防线

• 风险点（新增蔓延）：由于 DERIVED（衍生）和 CAPTURED（捕获）机制的存在，引擎会不断在磁盘上创建新的技能目录。我在 store.py 的数据库表设计中看到了 is_active（是否激活）字段，但没有看到定期清理（Garbage Collection）物理文件和废弃数据的强制删除逻辑。长期运行下，废弃或低质量的技能必然堆积，导致系统臃肿。
• 开发者的防线：为了防止 LLM 瞎改导致体积爆炸，开发者在 evolver.py 中设置了硬性截断 _SKILL_CONTENT_MAX_CHARS = 12000（Prompt中最多携带1.2万字符的技能内容），并严格控制了衍生技能的触发阈值（如 _MIN_APPLIED_FOR_DERIVED）。

2. 关于“混乱”的风险与防线

• 风险点（LLM 幻觉与代码破坏）：LLM 并不是完美的程序员，它可能会写出语法错误的 Patch，或者胡乱引用不存在的技能。
• 极其真实的防线 1（处理幻觉）：在 analyzer.py 中有一个非常有意思的函数 _correct_skill_ids，它使用了 Levenshtein 编辑距离算法。为什么要有这个？代码注释里无奈地写道：“LLMs frequently garble the hex suffix of generated IDs (e.g. swap cb → bc)”（LLM 经常把十六进制的 ID 后缀搞乱）。这说明系统在实际运行中已经出现了“混乱”，开发者不得不写死算法来纠正 LLM 产生的幻觉。
• 极其真实的防线 2（防死循环机制）：在 evolver.py 中，开发者设计了 _addressed_degradations 字典来记录“已经针对哪个工具的故障进化过哪些技能”。这是为了防止出现最可怕的混乱：Agent 改坏了代码 -> 执行失败 -> Agent 再次尝试修复 -> 再次改坏 的无限死循环。此外，对单次进化也限制了最多尝试 3 次应用补丁（_MAX_EVOLUTION_ATTEMPTS = 3）。
• 防线 3（血缘与指标追踪）：store.py 使用 SQLite 数据库严格记录了每个技能的“族谱”（skill_lineage_parents），以及调用次数、成功率、降级次数（total_selections, total_fallbacks 等）。这意味着如果一个技能被改得极度混乱，它的成功率指标会下降，最终被系统降权或重新回炉。

总结

该项目不是一个靠 PPT 圈钱的空壳项目，它确实写出了一套在当前技术栈下非常硬核且前沿的“Agent 自动编程与自我修复”框架。

但在事实层面，它无法完全摆脱 LLM 本身非确定性带来的熵增（臃肿与混乱）。开发者非常清楚这一点，所以他们没有依赖“LLM 会完美写代码”的幻想，而是用传统的软件工程手段（SQLite状态追踪、编辑距离纠错、重试上限、死循环阻断）给这匹野马套上了厚重的缰绳。短期内它可以表现出惊艳的“进化”效果，但长期持续无人工干预运行，数据库和磁盘目录的臃肿依然是一个待解的难题。

vibe coding堆高后的维护性极低的屎山代码，就像生物进化在基因里面遗留的屎山。但是生物屎山健壮（撸棒）性比代码高得多，可能是由于自然环境就像一个永不停止的高强度ci测试，打叉的立即会被淘汰掉吧。

虽然官方明确说了不会支持其他模型，但利用lite-llm这个转换器（类似命令行版的new-api），再使用环境变量让cli连接转换出来的api。

GOOGLE_GEMINI_BASE_URL=http://localhost:4002
GEMINI_API_KEY=sk-litellm-local

lite-llm配置如下，将openai格式调用转换成gemini格式给cli用

.openai_shared: &openai_shared
  api_base: 其他模型提供商url
  api_key: 密钥
  custom_llm_provider: openai
  timeout: 60

model_list:
  - model_name: qwen3.5-plus
    litellm_params:
      <<: *openai_shared
      model: qwen3.5-plus

router_settings:
  num_retries: 4
  model_group_alias:
    "gemini-3.1-pro-preview-customtools": "qwen3.5-plus"
    "gemini-3-flash-preview-customtools": "qwen3.5-plus"
    "gemini-3-flash-preview": "qwen3.5-plus"
    "gemini-3.1-flash-lite-preview-customtools": "qwen3.5-plus"
    "gemini-2.5-pro": "qwen3.5-plus"
    "gemini-2.5-flash": "qwen3.5-plus"
    "gemini-2.5-flash-lite": "qwen3.5-plus"
    "gemini-3-pro-preview": "qwen3.5-plus"
    "qwen3.5-plus-customtools": "qwen3.5-plus"

general_settings:
  master_key: sk-litellm-local

将示例的qwen模型改成自己的，然后运行litellm --port 4002 -c xx.yaml

认错也没用，你都不记得了。看来得试试那个末尾加上喵，不喵了代表上下文腐烂了的方法。不知道在哪看目前多少token了导致注意力涣散了，推测是10万左右