CVEN / LAB
项目页展示做成了什么；这里记录问题如何出现、我做了哪些判断、为什么这样取舍，以及这些经历如何改变后续工作方法。
最初让 AI 协助转换 DDL 时，结果直接把 string 设成固定 varchar，并混入了 Hive 风格的增量语法。SQL 看起来完整，但字段类型没有运行证据，原始产物也存在被覆盖的风险。
我负责判断哪些结论可以自动生成、哪些必须等待真实数据，并把纠正过程沉淀成后续任务都要遵守的交付规则。
先读取源 DDL 和依赖表字段类型，不根据字段名猜测 timestamp、string 等映射。
保留原 Hive 产物，新增独立 StarRocks 产物，分别约束 add columns 与 add column 语法。
先输出所有 string 字段的最大长度校验 SQL；没有结果时停止，不生成最终类型。
将长度计算、键前缀、字段顺序和表尾结构写入 Skill、测试与交付检查。
没有选择“一次生成完成”。多一次人工回填会增加交互步骤，但能避免由模型猜测字段宽度，并保留最终 DDL 的可解释性。
这次经历让我从“让 AI 写 SQL”转向“设计 AI 不能越过的检查点”：生成能力可以自动化，业务真值仍必须由数据和人工确认。
处理复杂 SQL 行数放大时，AI 最初倾向为主表和所有关联表生成重复检查，并使用 group by 位置编号。查询很多，但没有回答到底是哪一个右侧输入破坏了结果粒度。
我负责重新定义诊断目标：只检查 JOIN 右侧输入，按 ON 条件中的真实复合键判断，并解释哪些子查询已经收敛、为什么可以跳过。
排除主表，只枚举每个 JOIN 的右侧输入、别名和实际关联条件。
从 ON 条件提取右侧字段；复合关联逐字段分组，不使用 group by 1 代替。
检查 group by、distinct 和子查询输出；已按完整关联键收敛的输入直接跳过。
只对仍可能一键多行的右侧输入生成 GROUP BY … HAVING COUNT(*) > 1。
没有追求生成更多 SQL，而是先付出解析和粒度判断成本，换取更少、更准确、可以直接解释的排查语句。
我形成了一条稳定判断：排障工具的价值不是输出数量，而是缩小错误空间，并能说明每一次检查存在的理由。
Hive→StarRocks 和 JOIN 发散已经有稳定方法，但如果仍依赖每次对话重新描述，步骤顺序、人工结果、工具输出和最终制品之间无法形成持续记录。
我把真实数据研发问题定义为产品范围，决定首版不连接生产数据库、不伪造数据结果，并完成状态机、规则工具、工作台和双容器交付。
把类型映射、长度阈值、JOIN 右表和收敛判断从提示词移到可测试代码。
使用 received、analyzing、waiting、generating、validating 和终态表达执行过程。
缺少字符串真实长度时进入 waiting_for_human，只有回填完整结果才允许恢复。
SQLite 保存运行快照，前端展示制品、验证结果和工具 trace。
首版没有强行接入模型。正确性由 SQLGlot、显式规则和人工检查点保证，模型只保留为可选建议层。
这个项目让我进一步确认：Agent 工程化的核心是状态、工具、权限和恢复能力，不是让模型参与每一个步骤。
建表文档生成同时包含解析、模型处理和结果写入。同步请求把整个处理过程绑在一次 HTTP 连接上，耗时增加后容易超时，失败位置和历史结果也难以保留。
我负责把页面等待问题还原为任务生命周期问题，并在不额外引入 Redis、Celery 的约束下完成可部署的异步方案。
区分请求接收、任务持久化、后台处理、结果查询与失败收口。
使用 MySQL job 表和独立 worker，避免为低并发演示增加消息中间件。
前端轮询任务状态；后端保存处理中、部分成功、成功和失败信息。
检查进程重启后历史仍可读取，并让重置与任务处理共用受控锁。
数据库队列不是高吞吐场景的最终方案，但对当前演示规模更容易解释、部署和恢复；规模增长后再升级基础设施。
我学会先根据真实规模选择系统复杂度：架构不是中间件清单，而是对当前约束负责。
如果服务器每次拉代码后现场构建，依赖和环境可能漂移；预览通过后重新构建生产镜像，也无法证明上线的是同一份制品。
我负责把构建、预览、生产、Nginx 入口和回滚状态拆开，并依据自己的服务器条件调整原有部署方案。
CNB 使用完整 Git commit 构建镜像，不使用 latest 或分支名代表版本。
预览和生产使用不同 Compose 项目名、回环端口和状态目录。
预览验收后直接把同一 tag 提升到生产，不重新构建。
记录 CURRENT_TAG、PREVIOUS_TAG、部署锁和健康检查，失败时恢复上一版本。
相比托管平台，服务器方案需要维护 Nginx 和部署脚本，但更符合现有资源，也便于在本地与预览环境复现问题。
我对“完成”的判断从代码写完扩展到制品一致、运行健康和可回退；发布链路也成为项目能力的一部分。
个人项目需要证明真实工程能力，但源码、截图、构建产物和运行配置都可能残留公司域名、表名、账号或业务数据；只隐藏入口并不能形成安全边界。
我负责决定哪些事实可以公开、哪些必须重建，并让项目证据在不连接真实系统的前提下仍然可验证。
检查仓库、接口、静态资源、截图、日志、构建产物和容器环境。
使用独立仓库、合成数据和 demo_ 命名重新设计领域模型。
源码与构建产物执行敏感扫描，截图单独检查元数据与可见信息。
用测试、架构、trace、版本记录和本地演示替代真实系统入口。
公开案例不会复刻全部生产复杂度，但结构隔离比前端隐藏更可靠，也更适合在面试现场说明个人职责。
我形成了明确的交付边界：展示能力不等于搬运生产内容，公开证据也必须经过工程化治理。