chrome-devtool-mcp ai 操作浏览器，自己在浏览器登录账号后，除了刷帖子，操作浏览器全部交由 ai 。
skills 就是自家的 t-tools ai 写代码。
最近在看 orca ，期望它解决 codex 远程手机操作，但 worktree 对于我这种各种 rust 项目不太友好。

以下是我写于其它站，本想做个截图，但无法上传，故文字版贴出来：

2026/11/02 ，github 100 star 已达到。算是一个里程碑，加更一个更落地的公司级别如何引入 ai 协作的可操作方案，角度来自于研发负责人。
First and most important! 辅助一号位使用 ai ，ai 对公司的本质是生产资料、生产方式，尤其是以代码为生的公司，需要一号位基于对 ai 的认知重新梳理金钱资源分配、生产关系。
常规的代码生产关系破碎掉，代码生产主体从研发人员转变到产品经理、一线员工。
研发人员职责转化为复杂代码管理以及代码托管运维。
产品经理、一线员工是 vibe coding 来源，研发人员要审计他们的产出，并为产品经理、一线员工提供 vibe coding 最佳实践技术咨询支持。

若公司大， 研发人员需要提供从 Coding IDE 给到其它人员，包含审计、LLM 路由、编程最佳实践等，若公司小则培训、代码托管为主。

公司核心数据需要有个一个 data source service 围起来，其余人员不可接触密钥等，所有涉密的都走 proxy 、内置审批等，要明确认识到：

一定有人会把代码、密钥会暴露到公网。
一定有人给 ai 所有权限，不做审计，ai 会犯浑。
一定有人会拉一坨 ai coding 大便，交给研发人员承接。
一定有人会安装有毒 skill 。
一定有人会将 vibe coding 的产出理解成是自己的不是公司的，尤其是 token 自己买的时候。
不要一头扎进去把所有的需求揽到研发部门，揽不完的，其余部门也会拿自己的 vibe 成果来比对你产生的代码速度太慢。

不要开会去了解各部门的需求，各部门无法在会议期间明确他们到底要什么，即使你提供了高保真原型图，也只是一时，他们会不断地将研发部门的产出速率和自己 vibe 速率做对比。

所以：
一定要培训，一定要告诉他们 vibe coding 产出的东西，在没有严谨的 harness 流程加持下，产出的都是“垃圾”，都是不可维护的“定时炸弹”。

一定要做核心数据、密钥隔离，其它部门可以 vibe ，但不能拿到密钥，尤其是可改动核心数据的密钥。

一定将 vibe coding 的产出物托管到云平台的 serverless 或 k8s 集群，做好网段隔离、和资源监控，随时强关服务。

一定要提供如何部署 skill ，这个会影响技术选型，如果不做，python 、pg 、js 、supabase 选型都是轻的，最怕所有数据以文件方式存储，随便托管到外网，还没有鉴权，代码加密钥在 github 上开源。

@klos 人工，还是自动化？

结合已有的 openspec ，superpower ，gsd 等构建类似我这种 skill harness： https://github.com/timzaak/web-dev-skills 。

一个项目开两个窗口，一个跑 skill 流程，一个根据上一个的产生物修正 skill ，不要尝试去看代码，而是要将代码指令验证交给 AI 来做。这时候卡住你的只有 token 吐出速度、项目编译速度。

目前阶段，后端可以做到口播一个 task ，然后 ai 跑通所有，前端还需要人工校准。

等自己的 skill harness 成熟后， 可以同时搞多个项目， 这时候卡住你的就是电脑数量、token 成本和想法了。

我自己用 zcode max + codex plus 。可以支持三个项目的开发。
其余的就看你能从哪个平台拿到 token plan ，哪个平台的编程工具就是好的。

1. 自己越来越不会写代码了
但你应该越来越会“管理代码”。

2. AI 写的代码有些啰嗦，有很多不太优雅
各种用于简化代码的 skill ，检查代码重复的工具，你会用得越来越顺手。

2. 对项目的把控很低，害怕代码有问题
高强度的代码测试用例覆盖缓解代码逻辑问题， 代码鸟瞰图、项目观察工具会被开发出来，进而应用到当前项目中去。

1. 所有仓库全部放在一个目录下，在此目录下工作。
2. AGENT.md 里标注关联仓库的具体位置及作用。

描述产品是什么、验收标准描述、验证产品（验证代码、跑、修复 bug ），是超级消耗 token 。人力也要考虑进去，所以成本并不低

@coderwitt @conky 这个需求这么小众，两位大佬是怎么做到如此快的留言关联性极高的帖子的？

navicat 很多时候是为了审计采用，要么很多免费的 sql client 也够。

发现问题，定义问题，解决问题。

软件架构先从可观测性入手。可观测性又分为：软件运行时可观测性，开发可观测性，用户可观测性。

软件运行时可观测性目前业界主流就是 OpenTelemetry 那一套，再补充程序崩溃上报。
开发可观测性考虑的是协作流程，以及问题/feature 闭环，以前主要是瀑布流、TDD 等来解决，现在 人类和 AI 协作上还没有很好的可观测方案。
用户可观测性就是用户分析那一套， 开源项目有 umami ，postHug ，免费资源 google analaysis 。


定义问题：大部分程序性的问题，在 AI 的加持下，都不是问题，剩下的非程序性问题， 就要思考维度介入，这个千人千面。

解决问题和定义问题一样，程序性问题没门槛，非程序性问题，例如：程序到底多快才可以，要承载多少用户才可以，动画流畅性到底多少 fps 才达标...，这些 ai 只能告诉你业界的最佳实践是什么，但如何取舍还是靠自己。没有营养的说法是：将手头上的资本资源、人力资源、已积累资源做个整合，解决主要矛盾，减少对次要矛盾关注。

如何提升，虽然不想，但还是忍不住将其归结为“天赋”。

应该类似先前的云厂商，干脏活、累活。至于插件形式，按照大厂的尿性，一定是想做自己的生态，让你离不开他们。

个人开发者开发插件，很难搞定收费问题。

1. prd ，用户故事 进入 git 管理
2. skill + subagent 要明确说明查阅 ... prd 、用户故事 文档
3. 定期整理 prd 、 用户故事文档, 确保和代码实现具有一致性

From 我自己维护的 AI 自动化 Web 开发 skills https://github.com/timzaak/web-dev-skills)

@Haku rust 编译产生的中间产物占用空间很大，最终产品还是小的

我的 rust 项目 target 目录经常 100GB 。代码行数不到 50w ，编译也很慢。 若是产品功能导向，还是慎重为好

看做什么，最好让 ai 抄一个网站构建出 design.md 然后 再让 ai 梳理出想要的网页结构，再输出页面

从不用 memory ，每次都是初恋

自己做个 skill collection ，我做的是 https://github.com/timzaak/web-dev-skills ， 用 t-init 初始化项目。从第一行开始 ai 来做。