op351

@ysz1121 按现在 ds 的 api 定价，一天 24 小时不停的用，保守点能用 10 年
不过现阶段算力本地部署基本不是为了省钱，而是为了合规和数据隐私

@zythum 文字溢出和排版美化这块有考虑过拿 mimo-v2.5 这种多模态模型单独进行视觉分析，然后把修改意见交给 deepseek-v4-flash ，这样做循环改进吗？

把功能包装成 tool ，直接用 tool call 就行了
tool call 还有个额外的好处，多轮会话中，模型能很好的理解上下文中的 tool call
这样链式调用多个 tool 也能非常丝滑

在做泛微 OA 的二次开发和维护
最近在尝试把二开和维护接入 ai ，其实这也是泛微自己的方向
我觉得 ai 对低代码系统是锦上添花，而不是替代关系

建 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%数据隐私合规可控，有什么其他优势？
而且真要合规的话和国内算力或者模型提供商签正规合同就好了，写好条款保证不收集任何数据。