在开发项目的注意点-尧图网络科技

1.要把握项目实体
架构实体

如果要涉及多个项目，不同架构进行交互
第一步就是配置
做好配置以后，才可以去进行开发

对于系统交互的入口，
要注意的点
这层是一个很麻烦，很重要的点

你说到根子上了。“配置即契约”——这才是分布式系统开发的铁律，而不仅仅是AI开发的问题。

你刚才那三个错误（忘Token、编账号、丢Bearer），本质根源只有一个：AI把“业务逻辑”当成了主角，而把“配置和入口”当成了可以随手扔在main.py顶部的几行常量。

但在真实的多项目、多架构交互中，配置层是“物理层”，入口层是“链路层”。这两层不落稳，上面写的所有逻辑都是空中楼阁。针对你提出的这两个核心痛点，我帮你把它翻译成AI无法绕过的“物理护栏”：

1. 关于“把握项目/架构实体”——让AI先画“配置拓扑图”

AI默认是“文件视角”（只盯着当前打开的代码），而你需要它是“网络视角”。在写任何requests.get之前，强制它生成一个《环境配置矩阵》，并且明确告知：“不看到这个矩阵，绝不生成调用代码”。

你可以直接把这段指令贴在Prompt里：

【强制前置-配置拓扑】
在生成任何系统交互代码前，请先输出该模块的config.yaml或pydantic-settings结构。
必须包含以下三类实体：
系统实体（System-A/B/C各自的base_url、timeout、retry次数）；
认证实体（Auth端点、Client_ID/Secret的环境变量占位符，严禁出现具体值）；
路由映射（不同架构——比如老SpringBoot与新Go微服务的API Path前缀差异）。
校验标准：这份配置结构必须保证，仅需修改.env文件，就能切换Dev/Test/Prod环境。配置未确认前，代码止步。

——这一步能把你从“报错改配置”的泥潭里拉出来，因为AI一旦把配置抽象成Settings类，它后续调用时，就不敢硬编码localhost:8080了。

2. 关于“系统交互的入口层”——把它视为“安检站”

你提到这层“很麻烦、很重要”，太对了。入口层（Gateway/Adapter）不是简单的http_client.post，它肩负着：协议转换、熔断降级、链路追踪、以及你刚踩坑的凭证续期。

AI最讨厌处理“异常分支”，它总假设网络永远畅通、Token永远有效。所以，针对入口层，你要给它下一个“全量异常覆盖”的死命令：

【入口层硬性规范】
生成所有外部系统调用的**入口函数（Entry Point）**时，必须采用“包裹器模式（Wrapper）”：
前置：每次请求前，检查Token是否过期或为空，若为空立即抛出ConfigurationError，不允许启动服务。
请求中：Header的Authorization必须显式拼接Bearer（用断言assert锁定）。
后置：必须处理401/403，触发自动刷新Token或记录明确日志（“Token invalid, please check env: AUTH_ENABLED”），绝对禁止静默失败。
强制日志：入口层出入参必须打印logger.info（脱敏后），方便你排查是“代码错了”还是“网络不通”。

给你一个“一劳永逸”的Prompt套路（专治多系统交互）

以后面对这种需求，别再上来就“帮我写个调用接口的函数”。直接甩给它这段话，把“配置”和“入口”锁死在开发的第一阶段：

任务：实现【系统A】与【系统B】的订单状态同步
第一阶段（只做配置，不写业务）：
请创建config/目录，定义pydantic.BaseSettings子类。
包括：SERVICE_B_URL、CLIENT_ID、CLIENT_SECRET。若环境变量缺失，Validator必须抛出明确的MissingEnvironmentError并终止进程。
第二阶段（只建入口，不写循环）：
请封装BServiceAdapter类。构造函数接收Settings实例。
提供唯一的_request(method, path, data)私有方法。
在该方法中：
① 强制检测Token是否存在；
② 强制加Bearer；
③ 强制设置ConnectTimeout和ReadTimeout（各5秒）；
④ 捕获requests.RequestException统一转为业务自定义异常BServiceUnavailable。
第三阶段：基于上述Adapter编写具体同步逻辑。