op351

建 wiki 文档的思路是对的
但是可以考虑在每个子项目内建立对应的 code analysis summary ，而不是整个项目一个 wiki
在子项目内部开发时，确保每一次更新提交都更新对应的 code analysis summary 。
然后子项目开发时如果遇到外部调用的时候，让 agent 自己去读其他子项目的 code analysis summary ，然后他自然会去理解对应的业务逻辑，如果链式调用的话，也是一样的逻辑。
单独建一个 wiki 项目去做项目下所有子项目的文档维护的话，我觉得维护成本有点大。

300K
超过 400K 之后，不仅仅是幻觉，死循环
模型开始连工具调用都频繁出错
一般超过 300 之后我就开始把这一轮的更改都自动 review ，收尾，然后开新的对话了。

跳槽呗
跟公司耗着没意义 除非你快退休了或者工龄非常长

我说一下传统开发移植的时候是怎么做的
前期准备：
1.把所有功能都整理出来，形成文档
2.把后台数据库的数据结构理清，形成文档
3.把所有 api 都过一遍，形成 api 文档
新项目开始前准备：
1.讨论新项目架构，划分所有主要功能模块的设计
2.实现一个原型工程，只包含主要模块，也可包含部分子模块
3.组建开发团队，切分主要功能下的所有子功能，原则上将功能关联性较高的子模块分配给同一个人进行开发
开发中：
1.个人开发时，需要遵循原型工程进行开发，首先需要理解分配给自己模块的功能，数据结构，api 接口
2.在正式代码之前，需要理清数据的流向（这一步非常重要）
3.对于原本业务逻辑非常复杂的功能，实际移植时其实是非常容易发生错漏和偏移的，这个其实在编码阶段无解，只有通过后一个阶段构造完整测试集来进行排除
测试阶段：
1.通过构造大量测试 case 对新系统进行测试，构造是可以参考旧系统的测试集
2.通过测试，反馈 bug ，更改代码来实现新系统健壮性的逐步提升

至于 AI 做移植，我觉得可以参考以上流程

现阶段本地部署除了能保证 100%数据隐私合规可控，有什么其他优势？
而且真要合规的话和国内算力或者模型提供商签正规合同就好了，写好条款保证不收集任何数据。

小程序审核只是对个人和公司麻烦
如果涉及到学校或者政府这种 审核上就开绿灯了

看着优点是支持多个 session ，甚至跨项目的 session 在同一个窗口里运行和管理
但默认只支持 cli ，应该底层是多开 copilot-cli 实现的

我是 91 刀
不过也说明 claude 和 code 目前中度 code 套餐 100 刀的定价是合理的
在合理使用范围下 一般用户是有一定的利润 当然重度用户就不好说了 应该是会亏的

不论报不报销，都得会用，甚至要深入的用，各种模型切换着用，各种工具切换着用。
这样以后跳槽写简历，面试就能开吹了。