AI 应用与全栈工程
多模型接入、事件驱动架构、多租户权限、业务图谱、开发者工具与验证流程。
ABOUT / WORKING METHOD
把复杂现场变成有边界、有证据、能复查的工程链路。
我是金木，一名横跨 AI 应用、全栈工程、Web 逆向与 Python 自动化的开发者。
我通常从协议、数据和架构关系开始理解问题，再把分析结果收敛成可以运行、可以验证、也能继续维护的系统。对我来说，“功能已经写出来”只是中间状态。更重要的问题是：它遵守了哪些边界，改变了哪条业务链，失败时能否定位，以及最后由什么证据确认完成。
METHOD / HOW I WORK
我处理问题的方式
面对复杂系统，我习惯先区分事实、猜测和缺失信息。协议分析中，我会把算法、会话、请求环境、传输层和业务结果拆开，不因为签名字节一致，就直接推断真实数据链路已经成立。
架构治理中，我会沿着组件、事件、接口、权限和数据访问继续追踪影响范围，不把文档约定当成已经生效的工程规则。自动化任务中，我更关心正确身份、执行顺序和最终状态，而不是某个按钮是否被点击。
这套方法通常包含四步：观察现场、建立模型、提取最小复现、分层验证。不同问题需要不同的完成证明：有时是字节对齐，有时是类型与测试通过，有时必须回到数据库或真实业务状态再次确认。
WORK / CONNECTED CAPABILITIES
公开内容覆盖的工程能力
这些内容共同回答：怎样把难以观察、容易误判的过程，改造成能够复查的工程系统。
Web 逆向与协议分析
JavaScript 虚拟机、WASM、AST、签名与加密链路、会话和传输层对照实验。
Python 自动化交付
数据采集、桌面控制、浏览器与协议通道、异步队列、多实例隔离、数据库终态确认和桌面打包。
BLOG / FACT BOUNDARIES
这份博客记录什么
博客不是简历的延长线。主页负责快速展示项目、能力和公开证据；这里更关心判断形成的过程。
我会写已经确认的实现，也会写设计为什么被删除、一个测试究竟能证明什么、某个指标为什么仍然不可信，以及下一步应该怎样验证。文章不要求每次都得出最终答案，但会尽量明确区分事实、覆盖、推演与未知。
目前的文章主要来自真实工程材料。工程之外的内容只有在出现可公开的原始笔记、阅读记录、聊天或其他素材后才会加入，不会为了让页面显得完整而补写经历和兴趣。
SELECTED READING / SIX PROOFS
从六种能力证据继续读。
不只选择最新文章，也不让全部代表作来自同一个 AI 工程项目。
我删掉了一套数学上正确、工程上无效的学习闭环
当模型自报概率无法穿过会话边界，我把校准器改成了案例库、真实结果与下一次任务真正看得见的记忆。
AI EngineeringCase MemoryDeveloper Tool
签名正确，为什么 API 仍然不给真实数据？
一次把签名、会话信誉、TLS / H2 指纹和行为环境逐层拆开的逆向对照实验。
Web ReverseTLSA/B Experiment
自动回复的终点，不是点击“发送”
从 64 张加密消息分片表到数据库二次确认：如何把客服自动化从 UI 动作推进到可验证的业务闭环。
AutomationSQLCipherFinal State
多租户隔离，不是给每张表加一个 tenantCode
从登录态、账号域、模块开通、RBAC 到数据访问：多租户边界必须成为服务端可验证的执行契约。
ArchitectureMulti-tenantRBAC
四十项测试的证据账本
把 14 项历史案例、9 项相似性检查和 17 项不变量按 oracle 与边界重排，不把通过数量当成可靠性分数。
TestingProperty-Based TestingReliability
让错误 Markdown 在发布前失败
从 front matter、策展引用到 featured 数量，记录哪些内容错误已经硬失败，哪些曾经只是静默退化。
Next.jsContent EngineeringStatic Export
CONTACT / OPEN TO ENGINEERING OPPORTUNITIES
如果问题值得拆开验证，欢迎联系。
适合交流的问题包括 AI 应用工程、全栈架构、Web 协议分析、Python 自动化，以及需要从复杂现场中建立验证闭环的工程任务。