zsyevan

结合已有的 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 只能告诉你业界的最佳实践是什么，但如何取舍还是靠自己。没有营养的说法是：将手头上的资本资源、人力资源、已积累资源做个整合，解决主要矛盾，减少对次要矛盾关注。

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

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

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