🤔☕️🤔☕️🤔 【R】限制：LLM每次能处理的输入与输出token数量。 关键：从架构设计和测试策略两个维度，将需求分解到足够小的任务。 LLM：任务分解 + 测试代码 + 生产代码。 架构：指导每日工作的任务划分。 测试：TDD + PP with LLM。 PP = Pair Programming 【.I.】LLM的Context Token数量，似乎是它的缺点，看到那个谁已经整得很大，眼看着能把整个代码仓扔进去，貌似很好的样子。可是，我倒认为，这样的限制，实际上可以利用起来，发挥出局部性的聚焦优势。无论我在多大的代码仓里干活，我实际要做的事情，越是在局部，越是能够做得干净利落，越是跟其它耦合，那就拖泥带水踩坑前行。 【.I.】架构，这个词写出来，总有点看似高级又不明所言感。实际上，还不是手头有怎样的兵，就会演化出怎样的架构，无论写在纸上还是落进代码仓里。如今，LLM作为新兵入队，自然会变成影响演化的力量，差别在于，LLM凭自己的生命力，见空就座，还是听话就座，我猜测是前者，而且我相信我的猜测是对的，LLM的力量在于，只要坐下来，就会黏住。 【Q】团队是否也有Clear、Complica、Complex的认知状态？如果有的话，怎么能判断出来当下团队整体处于什么样的认知状态？ —  by 术子米德@2024年4月12日