ARTICLE · 1200042
没有源码,Codex 能看懂内网终端管控软件吗?
没有源码,Codex 能看懂内网终端管控软件吗?
信息科接手一套软件，最头疼的场景是什么？安装目录还在，程序也能运行，但源码没有、文档不全，出了问题只能沿着文件和日志一点点摸。 这次，我把一份内网终端管控软件目录交给 Codex，只输入了一句话： “分析软件功能和架构。” 
截图里的第一轮动作很有代表性：它先查目录结构和项目标记，再读取配置与脚本。这篇文章就从这个起点，聊聊没有源码时，如何让 AI 帮我们把一个陌生软件逐步分析清楚。 01 / 先弄清楚：我们手里到底是什么 Codex 首先尝试寻找 AGENTS.md、README、package.json、sln、csproj、pom.xml 等文件。这个动作是在判断：当前目录是源码工程，还是已经编译完成的安装目录？ Get-Location rg --files -g AGENTS.md -g 'README*' -g package.json -g '*.sln' -g '*.csproj' -g pom.xml rg --files 如果找不到工程文件，只看到 EXE、DLL、INI、BAT，后续就应该转向安装包和运行行为分析。项目标记缺失只是线索，不能单凭这一点宣布“没有源码”。 截图中能看到对 JCSet.ini 的读取，以及对一个卸载批处理文件的查看。这里应当分清两个动作：读取脚本是在找线索，运行卸载脚本会改变系统。分析起步阶段只需要前者。 电脑没有 rg 的可以使用winget手动安装： 02 / 配置和脚本，是最便宜的线索 黑盒分析不等于一上来就反编译。先看配置、说明和日志，往往就能知道程序打算连接谁、在哪里写日志、启动时需要哪些参数。 Get-Content -LiteralPath .\JCSet.ini 如果中文乱码，先确定文件编码。PowerShell 7 可尝试按 GBK 读取；UTF-8 文件则使用 UTF8。不要把解码错误当成程序加密，更不要直接保存覆盖原文件。 Get-Content -LiteralPath .\JCSet.ini -Encoding 936 Get-Content -LiteralPath .\JCSet.ini -Encoding UTF8 让 Codex 按“原始字段—所在文件—可能用途—待验证项”整理结果，会比一句“这是服务端地址”更可靠。某个配置值看起来像管理地址，也可能只是历史配置；必须结合实际运行证据。 03 / 架构图必须沿着证据画 
终端管控产品可能涉及界面程序、后台服务、配置、日志与管理端通信。这只是待验证的结构假设，不能直接套在任何一个安装包上。 
可以看到触发codex的安全审查了，不过mysql连接信息、radmin连接信息已经获取到了。 04 / AI 最有价值的，是把排查过程变得可追溯 过去，接手一个陌生软件，我们往往是在文件夹、服务列表和日志之间来回切换。Codex 可以协助完成检索、对照和整理，把零散线索变成下一步能验证的问题。 但“看起来合理”还不够。一个有用的交付物，应该说明软件有哪些模块、每项判断来自哪里、还有哪些未知，以及下一步怎样用最小代价验证。 没有源码，依然可以建立理解；有了 AI，更要让每个结论都找得到证据。
winget install --id BurntSushi.ripgrep.MSVC --exactini、conf、properties、xml、json等文件通常含有比较重要的配置信息。
