旧论坛在旧系统上运行多年( 2013 年左右开始建站、17年之后就很少维护了 )。
最近 PHP 爆了几个漏洞，还有梯子频繁被封 IP，就调整了一下架构。
然后一起把漏洞处理一下。

新版 Discuz 对 PHP 的要求已经超过旧环境，原地升级会让操作系统、运行时、数据库和论坛程序一起变化。
结合 aws LightSail CPU 突发型的实例，尽量降低 CPU 占用，避免影响线上服务。
所以就先把 Discuz 程序代码 + 数据库文件拉到本地，用 docker 的方式进行迁移验证。

近期 AI 爬虫是真多，迁移快完事的时候，把我站点都打挂了。
一个没什么人访问的老论坛，在线人数直接创新高。

总计 1058 人在线 - 最高记录是 30437 于 2026-11-3

津晶在访谈中自述，她同时在推进 400 多个 feature，工作区里有 400 多个 worktree，其中 200 多个按固定流程自动运行。这些数字不能证明团队产能，但能说明她管理任务的方式不是逐个查看 Agent。重复工作交给自动化和 Agent 之间的协作，人只处理无法标准化、影响权限或需要承担结果的部分。

人一旦被叫来，系统不应丢一整段日志或开放式问题，而要把处境整理成 2 到 3 个互斥选项，写清影响、风险和推荐答案。

这也是 ADE 和普通终端的分界。终端保存会话，ADE 还要把任务、状态、例外和选择放进同一套结构里。

2026 年 10 月 19 日，PingCAP 发布安全事件公告。公告确认，2026 年 9 月 9 日至 10 月 7 日，外部人员使用被盗服务账号访问内部系统，复制数据并获取源代码。

事件的影响不限于数据库本身。被盗身份能够访问控制面相关数据、支持材料、查询历史和导出路径，风险可以沿客户凭据继续进入客户自有云账号。

想到早几年有一位同事把工作环境的密码，不慎传到个人 GitHub 仓库，违反公司红线，绩效、晋升都受到影响。所幸泄露没有造成业务影响。

1. 事件摘要

PingCAP 公告确认了四项内容：

• 未授权访问窗口为 2026 年 9 月 9 日至 10 月 7 日。
• 导出记录包含用户名、邮箱、组织与项目关系、SQL 编辑器文本和错误、部分集群标识，以及合同、订单、定价和计费配置。
• 导出表中存在加密的 TiDB Cloud API Key。
• 外部事件响应团队发现 4 个漏洞，PingCAP 已于 10 月 14 日完成修复和复测。

李录是喜马拉雅资本创始人，长期管理芒格家族部分资产。
他首先是个投资者，不是技术专家。
这个身份决定了他的问题顺序：这项技术能做什么，谁靠它赚钱，价格是否合理，风险是否超出承受范围。

李录对 AI 的判断，最容易被压成一句「AI 只是工具」。
原话比这复杂。他说 AI 正在从工具走向生命体，但人类必须把它按在工具这一侧。前半句承认能力在变，后半句是规范判断。

2026 年 10 月 5 日，他在哥大商学院第 36 届格雷厄姆与多德年度午餐会上，系统谈了对 AI 的看法。

1. Agent 系统的构成

Agent 系统常被理解成模型加界面。这个公式能解释聊天产品，解释不了长任务、工具调用和生产环境。

模型负责理解、推理和生成。上下文怎么装配、工具怎么调用、状态怎么恢复、权限怎么控制、结果怎么验证，这些都不由模型决定，要由模型之外的工程系统承担。

把这部分拆开，可以得到 7 层：

1. 缘起

写这篇文章的起因是大家对 harness 概念理解有 gap。
我说某系统的表现主要由 harness 决定，
对方问，是不是那个 AGENTS.md 文件。

这类定义错位不是个例。2026 年上半年的几篇公开文章视角不同：

• LangChain 讲组件清单，
• Anthropic 讲多角色闭环，
• OpenAI 讲执行环境改造。各家结论并不冲突，但缺少统一框架。

因此本文系统梳理一次：从最小组成推导，再逐层扩展，最后落到三类真实场景的选型。

1. 软件工程是什么

1.1 本质追问

软件工程不是「写代码」，也不是「写文档」。它的核心命题是：

如何在不确定性（需求会变、人员流动、技术演进）中，让一群人持续产出可维护、可交付的软件。

这个定义里有三个关键词：

• 不确定性：不是已知路径的复现，而是应对变化的能力
• 一群人：协作规模是关键变量。一个天才能搞定的事，十个天才不一定能搞定
• 持续：做出来不算完，还要持续交付、持续维护

1.2 软件 vs 传统工程的根本差异

1. 背景与连接

桌面上的音频系统是 Mac Studio、魅蓝 HD2 小尾巴，加一对漫步者 S3000MKII 书架音箱。

1. 概览

AI Coding 的关键是让模型在正确时间拿到正确上下文。
把散在文档、聊天记录、邮件和成员脑子里的细节归拢到一处，让模型按需使用。
这样才能早日实现 one-shot 开发( 许愿式开发 / 一句话需求 )。

这份指南覆盖四个阶段：

• 新项目：搭上下文底座。
• 老项目：补齐代码读不出的约束。
• 日常需求：沉淀和复用上下文。
• 团队：把方法变成可维护的工程约束。

适合正在用 Coding Agent 的工程师和技术负责人。全文偏操作。
新项目从第 2 节读起，老项目从第 3 节读起，日常需求看第 4 节，团队推广看第 5 节，长期维护看第 6 节。

先从 Agent 的入口文件开始。
AGENTS.md ( Agent 主流入口，cc 也支持了 )是 Agent 的地图，只回答「去哪里找」和「什么时候看」：

短信不算笔记，但同样是散在外面的一份记录。既然要把这些东西收敛到本地，便签之外顺手把它也拿下来。脚本在 GitHub 上：phone-cloud-data-export/flyme-sms。

魅族云的短信备份页面还在，地址 cloud.flyme.cn/browser/sms-list.jsp。我账号里 1595 个会话、7600 条消息，最早一条是 2007 年，最后一条停在 2022 年初。

网页版没有批量导出，只能一页页翻。这篇和魅族云便签、锤子便签是同一批，都用浏览器里跑脚本的办法把数据拿下来，再在本地转成 CSV 和 Markdown。