# PY6mwULmXiWbhEkpO3wcYjPCnrh

Source: https://dianchukeji.feishu.cn/wiki/PY6mwULmXiWbhEkpO3wcYjPCnrh


# 一、工作概述
1.数值调研启动
2.对后续任务进行重新规划
3.优化了一下UI编辑
# 二、主要产出
## 2.1-数值调研启动
![图片](../feishu-images/PY6mwULmXiWbhEkpO3wcYjPCnrh_IayFb1x13onF.png)
订单表
![图片](../feishu-images/PY6mwULmXiWbhEkpO3wcYjPCnrh_Heuhb75K0oSk.png)
剧情表
![图片](../feishu-images/PY6mwULmXiWbhEkpO3wcYjPCnrh_AcgKbWqkHoCC.png)
棋盘空间表
![图片](../feishu-images/PY6mwULmXiWbhEkpO3wcYjPCnrh_GG5FblmLCo4w.png)
生产器表
## 2.2-对后续任务进行重新规划
重新明确两周后以项目上线为具体目标，与AI商讨调整的具体方案细节，具体化量化每天的产出目标。
![图片](../feishu-images/PY6mwULmXiWbhEkpO3wcYjPCnrh_JgwjbIk08olk.png)
![图片](../feishu-images/PY6mwULmXiWbhEkpO3wcYjPCnrh_GWp2bnc6eoeW.png)
![图片](../feishu-images/PY6mwULmXiWbhEkpO3wcYjPCnrh_XTihbvU1AoBI.png)
## **2.3-UI编辑优化**
**问题：**
  - 随着UI功能逐渐增多，读取加载的方式会显著拖慢项目的启动时间，影响功能测试效率
  - 同时UI编辑场景和运行场景分离不利于直接观察实际项目真实的UI布局
**改动：**
  - 将UI编辑功能转移到实际项目场景，便于直接观察实际项目真实的UI布局，减少来回导参数的成本
  - UI的布局缩放等参数直接在编辑器定死，不再走配置加载，提高了检测效率
  - 保留配置导出功能，保留项目的回档能力。
![图片](../feishu-images/PY6mwULmXiWbhEkpO3wcYjPCnrh_AXXTbtPdAoaQ.png)
# 收获和反思
## 3.1-收获
  - **参考优先：**在准备去实现一个功能/方案时，首先要做的是去寻找市面上是否有成熟的案例可以直接参考，避免空想导致想不全，想不到以及没目标等问题。同样的在与AI对话时，为了更准确的表达，应当多提供参考，包括源码、UI原型图、风格参考图以及工作流等，能保证效果落地更加可控。
  - **粒度控制**：将复杂任务拆解至AI可掌控的粒度。编程时单文件控制在500-1000行，单次对话控制复杂度上限；需求提交流程化（定义→拆分→确认→编码），避免上下文溢出导致“幻觉”和耦合。
  - **链路拆解**：将流水线切分为“人、AI、脚本”各司其职的环节。配表中剥离“填表”动作交由确定性脚本，AI仅负责规则设计与辅助校验；UI出图中拆分为“AI生成+PS人工微调+电图回传”，以半自动妥协规避全自动化40%的失败率。
  - **架构先行**：用前期架构设计的“慢”对冲AI快速堆积代码的“快”。坚持高内聚低耦合，系统间通过事件/接口通信，确保修改A不破坏B。
  - **对话与规范框架**：长对话分阶段总结写入MD重置上下文漂移；通过建立风格规范文档、更新日志约束AI输出；制作UI采取“最小可行性验证”，3-5张图测复现率，不可复现的风格需要考虑舍弃并寻找替代风格。
## 3.2-反思
  - **不可让渡决策权**：AI的犯错是隐藏的，AI交付的产物可能不会报错或者看起来非常合理，但很多问题会在实测试暴露，且再去维护会比较困难，因此人必须对结果具有验证和兜底能力——数值框架类的东西必须人来决定。
  - **用确定性方案做确定性的事**：AI本质是概率建模，不擅长精确执行。AI的思考的价值在于不确定领域的创意发散、设计讨论与启发式生成，而非自由执行。对于数值填充、公式计算等确定性和稳定性要求高的任务必须用确定性的脚本。
  - **避免无目标探索：**探索AI“工具”或“使用方式”时一定是要有明确的探索结果的，即它能解决哪些问题？不能解决哪些问题？对于当前的项目有哪些可应用的地方？如果有，应用后的结果如何？是否有改进的方面？是否值得继续深入探索？等一连串的问题确定清楚后，需要得出阶段性结论并回答本次探索对项目的增效是多少？
  - **避免宽泛交互**：向AI提需求需精确（截图+文字优于纯文字），要拆解具体的步骤；提问架构时，拿具体项目或竞品（如“梦幻西游UI管理逻辑”）去问，比问抽象理论更容易让AI产出具备实战价值的结果。
  - **在痛点中沉淀**：AI生成的架构分析偏教科书，缺乏实战细节。必须自己先在耦合系统中踩过坑，带着“弹窗层级怎么管理”这类具体问题去阅读开源代码，才能真正理解并指导AI。
# 四、明日计划
1.搭建剧情系统框架、设置系统框架、存档方案，所有方案与AI讨论，确定符合底层框架，与其他系统尽量解耦，明确影响范围和具体分段实现的计划后再进行开发
2.功能编码时，继续完成数据记录和调研，至少再推进10个剧情阶段，并尝试寻找是否有可供参考的二合数值框架用于辅助分析。
# 五、当前进度和规划

> [嵌入电子表格: Cuh1sB52mhRMWrtSwkNc...]