Agent的一天不是排日程，而是定义循环：感知、决策、执行、验证。早晨给它目标，中途它自己读文档、调API、写代码、跑测试，晚上回来验收结果。关键是把任务拆成可验证的里程碑，每个动作有回滚和重试。别把Agent当黑盒劳动力，要当实习生用：交代清楚验收标准，随时准备纠正。

还很远，但方向对了。Lean擅长把已知定理形式化并验证推导无误，相当于帮数学家做机械校对。真正困难的是提出问题、选择策略、判断哪些引理值得建立。AI目前能补全短引理、搜索已有库，但原创性和数学直觉仍是人的领地。未来更可能是人机协作：人定方向，机器填细节。

闻得到。GPT断言常见毛病：只验证存在性不验证语义、用contains硬凑、对边界值视而不见、Mock期望和实际调用对不上。评审重点看三处：是否测业务规则而不是实现细节、有没有反例能打破它、删掉被测代码后测试会不会无声通过。AI可以辅助生成，但测试的灵魂仍在于人对风险点的理解。

不是必选项，是手段之一。规模小、变更少、没有SRE能力的团队硬上K8s，维护成本会反超收益。数字化真正的核心是可演进：代码能持续交付、数据能打通、系统能水平扩展。虚拟机加CI/CD加容器同样能跑得很好。判断标准不是口号，而是团队能不能真正驾驭这套复杂度。

价格战短期利好账面上的云费用，但服务质量往往被稀释。降价空间常见来源：资源超售率提高、工单响应降级、SLA赔付收紧、新功能研发投入放缓。企业该盯的不是单价，而是单位业务的可用性成本——一次故障损失可能远超一年省下的钱。选型时把SLA、赔付、退出成本写进合同，比单纯比价重要。

这个症状九成是合法域名没配全。开发者工具默认不校验域名，正式版是强校验。逐项过：小程序后台「开发设置」的服务器域名里，request 合法域名是否包含登录接口完整 HTTPS 域名，不能带端口和路径；HTTPS 证书链是否完整，部分安卓机对不完整链更敏感；如果登录在 webview 里，还要配业务域名并传校验文件。常见坑是开发时开了「不校验合法域名」调试，问题被掩盖，上线才爆。手机上开调试或抓包看具体报错，是「url not in domain list」还是证书错误，定位就清楚了。

avoidSizeIncrease 的逻辑是转换后的体积比原图还大时，直接返回原图不处理。你看到的「空」多半不是真空，而是边缘函数把这个未处理的分支当异常吞了。排查：先用 curl 单测同一张图，看响应的 Content-Type 和 body 到底是原图还是空，确认函数里对这个分支有没有兜底返回。另外 WebP、AVIF 这类格式在小尺寸或低质量参数下，转换后体积确实可能变大，正好触发这个开关。建议小图直接跳过处理，或者把质量参数改成条件式的，别让开关替你做隐式决定。

多模态 Harness 的核心是把图像、语音、文档统一进 Agent 工作流，而不是各模态各建管道。落地建议先挑团队最高频的场景切入，比如客服工单里的截图识别加文本理解，用同一套 Harness 串联视觉模型和文本模型，工具层用统一协议（MCP 这类）对接。三个坑提前避开：一是多模态输入 token 成本比纯文本高不少，前置裁剪要做；二是评估指标按模态拆开测，别只看端到端准确率，不然分不清是视觉还是理解的问题；三是图片里容易带敏感信息，权限和审计要跟上。

能，但别神化。本体论的核心价值是把「数据的含义」从代码里挪到数据层：传统系统对接要写一堆字段映射、单位换算、状态翻译，胶水代码占集成工作量的大头。有了共享本体，上下游按同一套概念说话，胶水自然变薄。不过本体设计本身是重活，业务一变就得跟着改，维护成本不低。务实路径是先在核心域小范围建本体，长尾的字段映射交给大模型做语义对齐，人只维护核心概念和冲突仲裁，这样才真正省得下来。

删注释基本没用，AI 味主要在代码结构上：变量命名过于规整、防御性判空满天飞、抽象层级一刀切、每个函数都长得像模板。真要降低 AI 味，关键看人的改动痕迹——边界条件是否符合业务现实、错误处理是否贴合线上真实场景、有没有针对本项目约定做取舍。比较务实的做法是把 AI 生成的部分当初稿，关键路径自己重写一遍，reviewer 更在意的是这段代码懂不懂业务，而不是注释多不多。

典型的配置优先级问题。先查三个地方：一看回源协议的全局配置，确认选的是跟随协议还是固定HTTP，很多控制台里HTTPS相关配置会强制回源走HTTPS，优先级高于单条回源规则；二看有没有强制HTTPS跳转或回源HTTPS的开关在边缘层生效；三确认测试方法，用curl带响应头看边缘返回，或直接抓源站访问日志看实际进来的协议，别只看控制台显示。另外源站如果是443端口但回源协议设了HTTP，EO可能按默认策略自动走HTTPS。控制台配置和实际生效之间还有缓存延迟，改完等几分钟再测。还不对就带域名和请求时间提工单，让后端查实际回源记录。

因为稳定的技术不需要被替代。FTP、SSH、SQL、HTTP这些老东西能活几十年，不是行业保守，而是它们把问题解决得足够好，抽象层足够稳定。工程上换技术的成本从来不只是学习成本，还有数据迁移、周边工具链、团队心智、生产验证成本，加起来远超新技术的收益，除非新技术解决了老技术解决不了的核心痛点。反过来，天天追新的框架多半活不过三年，最后沉淀下来的反而是那些无聊但可靠的老组件。判断要不要换就看一点：老技术的局限是否真的卡住你的业务。没卡住就用，卡住了再评估替代方案，别为了简历好看换技术。