肖艺宣作品集

个人开源项目Open source2026.06–2026.09产品负责人 / 全栈Product owner / full stack

FlowPilot Lab · 供应链计划与决策平台FlowPilot Lab · Supply-chain planning platform

把"月度补货 → 周度发货"这套原本靠表格计算的流程，做成每个数字都能追溯来源的平台。I turned a spreadsheet-driven "monthly replenishment → weekly shipment" process into a platform where every number can be traced to its source.

2条计算链路（月度 6 阶段、周度 8 阶段）calculation chains (6 monthly, 8 weekly stages)

6条异常规则，自动发现风险risk rules flag issues automatically

31张数据表，覆盖需求、库存、在途、订单tables: demand, stock, in-transit, orders

0差异：重构 212 个文件后结果逐字段一致differences after a 212-file refactor

项目背景CONTEXT

基于供应链实习中接触的业务，把逻辑沉淀下来。供应链计划常见三个难题：数据分散在多张表格里，计划结果说不清是怎么算的，异常往往事后才发现。Built on what I saw in my supply-chain internship. Planning teams face three problems: data scattered across spreadsheets, results nobody can explain, and issues found only after they hurt.

项目成果OUTCOME

打通需求预测到周度发货的完整闭环End-to-end loop from demand forecast to weekly shipments
任意 SKU 可逐步追溯公式、输入和重算结果Any SKU can be traced step by step: formula, inputs, recomputed value
开源并附中英双语说明、计算链路图和规则文档Open-sourced with bilingual docs, a chain diagram and the calculation rules

GitHub ↗

我做了什么WHAT I DID

拆业务流程：拆成字段定义、业务规则和页面需求，覆盖风险发现、月度计划、周度履约、查询追溯 4 个环节。Process design: broke the workflow into field definitions, business rules and page requirements across risk detection, monthly planning, weekly fulfilment and traceability.
造数据、验系统：演示数据覆盖 5 个渠道、6 个产品分类、18 个 SKU；测试场景参考实习中的设计，模拟缺货、到货延迟、库存积压等情况。Data and testing: demo data spans 5 channels, 6 categories and 18 SKUs; scenarios modelled on my internship test design cover stock-outs, late arrivals and overstock.
查问题、修问题：抽样复算修正预测口径、汇率换算和回溯逻辑；核对数据发现两处隐藏口径错误，误判的异常 SKU 从 18 个降到 8 个。Finding and fixing: sample recalculations corrected forecast, FX and trace logic; reconciliation exposed two hidden definition errors, cutting falsely flagged SKUs from 18 to 8.
脱敏与重构：内部编码统一换成通用业务术语，改动 212 个文件，31 张表、2,267 行结果逐字段一致。Refactor: replaced internal codes with generic business terms across 212 files; all 31 tables and 2,267 rows matched field by field.

关键取舍Key trade-off

该如何判断优先级？How do you decide what comes first?

起初我想尽量完整地还原业务规则，把预测需求、现有库存、在途数量、交付周期、经销商优先级都算进去，让结果更精确。At first I tried to model every business rule (forecast demand, stock on hand, in-transit quantities, lead times, dealer priority) to make results as precise as possible.
测试中我发现，算对了不等于用户会用。系统只给出一个建议采购量，却说不清这个数是怎么来的，用户就很难信任它。Testing showed that a correct number isn't the same as a usable one. If the system gives a suggested order quantity without explaining where it came from, users won't trust it.
所以我把重心转向可解释性：每个建议都能下钻查看相关的库存、需求和在途数据，并看到异常情况如何影响这个建议。So I shifted the focus to explainability: every suggestion drills down to the related stock, demand and in-transit data, and shows how exceptions affect it.

复盘Looking back

如果重做，我会怎么改What I'd do differently

更早引入真实用户：先只做一个最核心的场景，比如“库存不足时怎么定补货计划”，做出最小可用版本，再根据反馈扩展其他模块，而不是先把功能做全。Bring in real users earlier: start with one core scenario, such as planning replenishment when stock runs short, ship a minimum usable version, then expand based on feedback instead of building everything first.
验证“有没有用”，而不只是“算没算对”：看用户能不能快速看懂建议、据此完成决策，以及系统是否真的减少了重复分析的工作量。Validate usefulness, not just correctness: can users understand a suggestion quickly, make a decision with it, and does the system actually cut repetitive analysis?

业务流程图：系统实际处理的范围PROCESS DIAGRAMS: WHAT THE SYSTEM ACTUALLY HANDLES

从 5 类数据源出发，每个字段的公式和两个关键判断：静态还是动态目标、是否超出配额From five data sources to the final quantity, with each field's formula and the two key decisions: static vs dynamic target, and whether the quota is exceeded

流程图来自项目 GitHub 文档，与代码中的计算规则一一对应 · 点击放大 · 手机可左右滑动Diagrams come from the project docs on GitHub and match the rules in the code · tap to zoom · swipe on mobile

左右滑动 · 点击放大 · Swipe · tap to zoom · 驾驶舱 · 数据看板 · 单 SKU 计算追溯（演示数据）Cockpit · dashboard · per-SKU calculation trace (demo data)

在线 Demo：打开即可体验Live demo: open and click around

无需安装和数据库，使用模拟数据，只读体验。No install or database. Demo data, read-only.

打开在线 DemoOpen live demo ↗

个人开源项目Open source2026.09 至今2026.09 – now产品负责人 / 全栈Product owner / full stack

PawPath · 动物收容与领养管理平台PawPath · Animal shelter & adoption platform

把课程 UML 设计做成真正能用的系统，让每次上架、每个领养决定都有规则可依、有记录可查。I turned a course UML design into a working system where every listing and adoption decision follows a rule and leaves a record.

5类角色：官员、员工、兽医、领养人、管理员roles: officer, staff, vet, adopter, admin

5种状态，每次流转都有前置条件statuses, each move gated by checks

6位申请人同屏比较适配度applicants compared side by side

22项越权访问检查全部通过access checks, all passed

项目背景CONTEXT

收容所信息散落在纸质和电子表格里，上架与领养决定难以追溯，多人申请同一只动物时也很难公平比较。Shelter records live in paper forms and spreadsheets, decisions are hard to trace, and comparing several applicants for one animal is guesswork.

项目成果OUTCOME

课程方案落地为可运行的网页应用，覆盖入所到回访全流程A working web app covering intake through follow-up
每次状态变更自动检查条件并写入审计记录Every status change is checked and written to an audit trail
开源并附业务规则文档、权限矩阵和状态图Open-sourced with business-rule docs, a permission matrix and state diagrams

GitHub ↗

我做了什么WHAT I DID

需求追溯：对照 UML 设计与新要求，找出状态模型、角色职责、入所流程 3 处冲突并制定方案；拆出权限矩阵、状态流转规则和 20 余项验收标准。Requirements tracing: found 3 conflicts between the UML design and new requirements and resolved them; defined a permission matrix, transition rules and 20+ acceptance criteria.
流程设计："上架准备清单"按负责人拆分前置条件，员工和兽医可并行推进；按儿童、现有宠物、独处时长、租房许可等条件给申请人打分；确认领养后自动关闭其他申请并安排回访。Workflow design: a readiness checklist split by owner so staff and vets work in parallel; applicant scoring on children, pets, hours alone and landlord permission; finalising closes other applications and books a follow-up.
测试验收：17 只动物、12 个账号、42 个品种的演示数据；自动化测试覆盖 22 项越权检查和完整领养流程；修复 Safari 点击错位、表单选项被重置等问题。Testing: demo data with 17 animals, 12 accounts and 42 breeds; automated tests for 22 access checks and the full adoption flow; fixed a Safari row-click bug and form resets.
体验与交付：按角色定制首页看板与待办，代码脱敏，中英双语文档与流程图。Delivery: role-specific dashboards, de-identified code, bilingual docs and flow diagrams.

需求建模基本功能力展示REQUIREMENTS MODELLING FUNDAMENTALS

项目 UML 展示（个人制作）Project UML (made by me)

点击放大Tap to zoom

左右滑动 · 点击放大 · Swipe · tap to zoom · 申请人排名 · 上架准备清单 · 员工看板（虚构演示数据）Applicant ranking · listing readiness · staff dashboard (fictional demo data)

在线 Demo 制作中Live demo coming soon

无需安装和数据库，打开浏览器就能点击体验完整流程。No install, no database: click through the full flow right in your browser.

团队项目 · 7 人Team project · 7 people2026.06–2026.08产品经理Product manager代码为团队私有仓库Private team repo

AI 旅行规划师AI Travel Planner

输入目的地和日期，自动生成按天可执行的行程（天气、景点、酒店和最优游览路线），并在地图上联动展示。Enter a destination and dates to get a day-by-day plan with weather, sights, hotels and optimised routes, shown on a linked map.

7人并行开发，接口先行people building in parallel

1–14天，支持的行程长度days per trip

2种算法：K-Means 分天 · TSP 排路线algorithms: K-Means days · TSP routes

秒级Seconds简单需求即刻生成，复杂行程约 5 分钟for simple trips; ~5 min for complex ones

项目背景CONTEXT

做攻略要在天气、地图、攻略和酒店平台之间来回切换；直接问大模型又常出现地点错误、路线绕路、信息过时。我们验证"大模型生成 + 真实数据 + 确定性算法"的做法。Planning a trip means hopping between weather, maps, guides and hotel sites, and asking a chatbot often gives wrong places and zig-zag routes. We tested combining an LLM with real data and deterministic algorithms.

项目成果OUTCOME

跑通"输入需求 → 获取数据 → 算法规划 → 地图展示"完整 DemoA working demo from request to data, planning and map
无需任何 API Key 即可完整体验Fully usable with no API keys

我负责的部分MY PART

立项与分工：组织需求分析和技术选型，把产品拆成地图、路线、后端、规划等模块，完成 7 人分工。Scoping: ran requirements and tech selection, split the product into map, routing, backend and planner modules, and assigned 7 people.
让 7 个人并行开发：搭建代码库和工程骨架，"先定接口、用模拟数据解耦"，持续协调地图、路线、后端模块的数据格式。Parallel delivery: set up the repo and skeleton, agreed interfaces first with mock data, and kept map, routing and backend formats aligned.
借助 AI 开发前端：用 Next.js 串联天气、高德地图和规划算法，行程列表与地图联动，适配手机。Front end with AI: built the Next.js app linking weather, AMap and the planner, with list–map sync and mobile support.
为"出错"做设计：外部数据不可用时切换演示数据，并在页面上明确标注，不把模拟信息当真实信息展示。Designing for failure: when a data source is down the app switches to clearly labelled demo data instead of passing it off as real.

团队共同实现BUILT BY THE TEAM

高德地理编码与景点、酒店检索 · K-Means 分天与 TSP 路线优化 · Python 后端与实验性的大模型规划流程AMap geocoding and POI search · K-Means day clustering and TSP routing · Python backend and an experimental LLM planner

系统流程：AI 和算法各管什么HOW IT WORKS: WHAT AI DOES, WHAT ALGORITHMS DO

① 用户需求① Request

🧳 结构化表单
目的地 + 1–14 天日期Structured form
destination + 1–14 days

② 数据获取（并行、解耦）② Data, in parallel

🌦️ 天气WeatherOpen-Meteo

📍 地理编码Geocoding高德AMap

🏯 景点 / 酒店Sights / hotels高德 POIAMap POI

🛟 失败时切换演示数据，页面明确标注On failure: labelled demo data

③ 确定性算法规划③ Deterministic planning

🗂️ K-Means 按天聚类K-Means: group by day

🧭 TSP 优化每日顺序TSP: order each day

④ 聚合展示④ Aggregate & show

🗺️ 行程卡片 ⇄ 高德地图联动Itinerary ⇄ AMap, linked

实验链路Experimental 💬 自然语言输入Free-text request🤖 大模型理解意图
提取目的地和日期LLM parses intent
destination & dates复用 ②③ 的工具和算法Reuses steps ② ③✍️ 大模型补充出行建议LLM adds travel tips

设计取舍：大模型只负责"理解需求"和"补充说明"，路线由算法计算，结果可验证、不会编造地点。实验链路已在 Python 中跑通，尚未接入线上默认流程。Design choice: the LLM only parses intent and adds explanations; routes come from algorithms, so results are verifiable and places aren't made up. The LLM pipeline runs in Python but isn't in the default flow yet.

左右滑动 · 点击放大 · Swipe · tap to zoom · 三日路线全景 · 第 1 天路线 · 首页（页面会标注演示数据）Three-day routes · day 1 · home (demo data is labelled in the app)

个人开源项目Open sourceClaude Skill2026.10设计与开发Design & build

PM/BA Panda · 从需求到原型的 Claude SkillPM/BA Panda · A Claude Skill from requirements to prototype

不是让 AI 直接写系统，而是让它先像业务分析师一样把需求挖清楚，再按 UML 一步步搭出经过验证的原型。Instead of letting AI write the system straight away, it first digs out the requirements like a business analyst, then builds a verified prototype from UML, step by step.

Skill 是给 Claude 的工作手册：一个包含流程、方法和脚本的文件夹。加载后，Claude 按规定的方法做事，而不是凭感觉发挥。A Skill is a playbook for Claude: a folder of workflow, methods and scripts. Once loaded, Claude follows the method instead of improvising.

21/21个故意埋入的错误，测试全部抓到deliberately planted bugs, all caught

61条验收标准，每条都有通过的测试acceptance criteria, each with a passing test

33项业务例外，逐项确认business exceptions, checked one by one

23个问题在实战中发现，已修进 Skillproblems found in a real run, fixed in the Skill

和直接让 AI 写有什么不同WHY NOT JUST ASK AI TO BUILD IT

先画图，再照图写代码。5 种 UML 图按固定规则变成代码：状态机管状态流转，权限矩阵变成服务端权限，测试也照着图检查。对比测试里，直接生成的版本有至少 5 个动作放错了泳道，序列图里还出现了类图中不存在的对象，照着写就是错的权限和数据结构。Diagrams first, then code that follows them. 5 UML models become code by fixed rules: the state machine drives status changes, the permission matrix becomes server-side access control, and the tests check against the diagrams. In a side-by-side test, direct generation put at least 5 actions in the wrong swimlane and used an object in its sequence diagram that its class diagram didn't have, which would have meant wrong permissions and a wrong data structure.
证明测试真的有用。测试全绿不代表能抓错。我故意埋入 21 个典型错误（规则、权限、计算、通知、界面），确认每个都被抓到；演示脚本也逐字自动排练，避免现场演示翻车（实战中就差点遇到一次）。Proof that the tests work. All-green tests don't prove they catch anything. I planted 21 typical bugs (rules, permissions, calculations, notifications, UI) and confirmed every one was caught. The demo script is also rehearsed automatically, word for word, so the live demo doesn't fall over (it nearly did once in the real run).
不懂代码也能把关。每个阶段停下来，只问 3–5 个业务问题；每条规则标明出处，推测的一律请你确认；材料和制度对不上时交给你裁决，不擅自改。You can review it without reading code. Each stage stops for 3–5 business questions. Every rule names its source, and anything inferred needs your sign-off. When the material and the policy disagree, you decide; it doesn't quietly pick one.

诚实的边界HONEST LIMITS

对比测试中，没装 Skill 的 Claude 在逐行核对材料、找矛盾上反而做得更好，我据此给 Skill 补上了逐行核对。目前只在“物品借还 + 审批”一个领域完整跑通过，下一步是建业务模式库、换领域再测。In the side-by-side test, Claude without the Skill was better at checking the material row by row and spotting contradictions, so I added a row-by-row audit to the Skill. So far it has been run end to end in one domain (item lending with approvals); next come a business pattern library and tests in other domains.

GitHub ↗验证报告 ↗Verification report ↗

用起来是什么样WHAT USING IT LOOKS LIKE

你描述需求，交出手头的台账、表单、制度（先脱敏）You describe the need and hand over your ledgers, forms and policies (de-identified)
它逐行核对材料，把隐藏规则和矛盾列给你确认It audits the material row by row and lists hidden rules and contradictions for you to confirm
写出用户故事和验收标准，画出 5 种 UML 图，每张配大白话说明It writes user stories and acceptance criteria and draws 5 UML models, each with a plain-language explainer
分阶段搭原型，每段跑测试和反向检查It builds the prototype in stages, running tests and mutation checks at each one
交付规格、原型、演示脚本和开发交接说明You get a specification, the prototype, a demo script and developer handover notes

我做了什么WHAT I DID

方法设计：7 阶段流程、评审关卡和一页评审摘要；规则出处标注；逐行核对台账的方法。Method design: the 7-stage workflow, review gates and one-page summaries; source tags on rules; the row-by-row ledger audit.
验证工具：UML 到代码的映射规则，以及 4 个脚本：本地渲染 UML、跨图一致性检查、追溯矩阵、反向检查。Verification tools: UML-to-code mapping rules and 4 scripts for local UML rendering, cross-diagram consistency, traceability and mutation checks.
实战迭代：先和直接生成做对比，再用 Skill 把一个虚构的设备借用系统从 9 行台账做到验收（150 项单元和集成测试、8 项端到端测试全部通过），把暴露的 23 个问题修回 Skill，写成中英双语验证报告。Real-run iteration: compared it with direct generation, then used it to take a fictional equipment-loan system from a 9-row ledger to acceptance (150 unit and integration tests and 8 end-to-end tests, all passing), fixed the 23 problems it exposed back into the Skill, and wrote a bilingual verification report.

左右滑动 · 点击放大 · Swipe · tap to zoom · 状态机图 · 按图生成的审核页 · 逾期归还收费（示例项目，虚构演示数据）State machine · the review page built from it · overdue return fee (worked example, fictional demo data)

课程项目 · 独立完成Course project · solo作业成绩 38/40（95%）Grade 38/40 (95%)Power BI · RapidMiner

贷款违约风险分析Loan default risk analysis

从原始数据到上线建议，独立完成一次完整的风控分析。A full credit-risk analysis, from raw data to a go-live recommendation, done on my own.

数据Data
发现 5,000 条记录缺失违约标签，另有"?"占位和异常值。统一清洗规则，并设计"违约率"指标，让不同人群可以直接横向比较。Found 5,000 records missing the default label, plus "?" placeholders and a malformed row. Set one cleaning rule and built a default-rate measure so groups compare directly.
看板Dashboards
两页 Power BI 看板，分别回答"哪类客户容易违约"和"哪些财务状况容易违约"，关键结论直接在图上标出。Two Power BI dashboards answering "which customers default" and "which finances default", with key findings marked on the charts.
指标Metrics
决策树Decision tree
像一连串"是 / 否"问题，把客户一步步分组，规则直观。准确率 89.3%，但 1,061 个违约客户只认出 35 个（3.3%）：违约客户只占 11%，全判"不违约"也能拿高分。A chain of yes/no questions that splits customers step by step; easy to read. 89.3% accuracy, yet it caught only 35 of 1,061 defaulters (3.3%): with 11% defaulting, calling everyone safe already scores well.
逻辑回归Logistic regression
给每个因素一个权重，算出违约概率；每个权重都能解释，也能检验是否显著。准确率 85.7%，但认出 315 个违约客户（29.7%），多 9 倍。Weights each factor to estimate the probability of default; every weight can be explained and tested for significance. 85.7% accuracy, but it caught 315 defaulters (29.7%), 9× more.
为什么选逻辑回归：对银行来说，漏掉一个违约客户的损失远大于多审核一个正常客户，所以"认出违约客户"比整体准确率更重要；而且放贷决定要能向客户和监管说清理由，逻辑回归的系数正好能解释每个因素的影响。Why logistic regression: for a bank, missing a defaulter costs far more than reviewing a safe applicant twice, so catching defaulters matters more than overall accuracy. Lending decisions also have to be explained to customers and regulators, and its coefficients show how each factor counts.
上线复盘Before go-live
识别率仍只有约 30%，需要调整阈值、处理样本不平衡后再评估。种族是显著变量之一，属于信贷中的受保护属性，上线前应剔除并做公平性检验。Recall is still ~30%, so the threshold and class imbalance need work first. Race came out significant; it is protected in lending and should be removed and the model tested for fairness before use.

客户画像看板 — 看板 1 · 客户画像Dashboard 1 · Customer profile

财务与信用风险看板 — 看板 2 · 财务与信用风险Dashboard 2 · Financial & credit risk

真实 Power BI 看板截图（课程提供的数据集）· 高亮框为关键发现 · 点击放大Actual Power BI dashboards (course dataset) · boxes mark key findings · tap to zoom

左右滑动 · 点击放大 · Swipe · tap to zoom · 两个模型的混淆矩阵 · 逻辑回归系数与显著性Confusion matrices for both models · logistic regression coefficients

课程项目 · 昆士兰大学 BISM7221Course project · UQ BISM72212026.05独立完成Solo公司与数据均为课程模拟Simulated company and data

一个住址，串起约 98 万美元的舞弊链One address, a US$980K fraud scheme

我用 SQL 检查一家公司的付款、工资和客户记录，查出一套持续多年、约 98 万美元的内部舞弊，并给出止损和长期防范方案。I used SQL to examine a company's payments, payroll and customer records, uncovered a multi-year internal fraud worth about US$980K, and proposed how to stop it and keep it from happening again.

约 98 万~$980K美元舞弊资金in fraud

10家假供应商，收款约 79 万fake vendors, ~$790K paid

5名假员工，年薪约 16 万ghost employees, ~$160K a year

1,119笔付款全部低于审批线payments, all under the limit

项目背景CONTEXT

一家从燃油发电转型 EV 充电的企业，委托评估 IT 治理、内部控制和舞弊风险。A company moving from fuel generators to EV charging asked for a review of its IT governance, internal controls and fraud risk.

体现的能力WHAT IT SHOWS

在大量数据里找到关键线索：假供应商、假员工、假客户都登记在同一个住址，顺着这条线串起三类舞弊。Finding the thread: fake vendors, ghost employees and a fake customer shared one home address, which linked three schemes.
从数字规律里发现问题：最高一笔 9,969 美元，全部"刚好"低于审批线，说明有人系统性地拆单绕过审批。Reading the pattern: every payment sat just under the limit, a sign of deliberate splitting to avoid approval.
追到根本原因：没有审批权的前台人员批准了 143 笔付款，财务负责人给自己的工资审批了 104 次。Root cause: a receptionist with no approval rights approved 143 payments, and the CFO approved her own pay 104 times.
把一次检查变成长期机制：6 条检查规则做成季度自动监控，异常直接报董事会。From one-off to ongoing: 6 checks turned into quarterly automated monitoring reported straight to the board.
用数字支撑决策：每条结论附金额和笔数，支撑"冻结权限、外部调查"的建议。Numbers that drive decisions: every finding carries amounts and counts to back an immediate access freeze and external investigation.

🗝️ 彩蛋：假供应商记录里藏着一串乱码，用凯撒密码（字母移位加密）解开，写的是 "This fairly obviously is NOT fraud!!!!"Easter egg: a scrambled string hidden in the fake vendor records decodes, with a Caesar cipher, to "This fairly obviously is NOT fraud!!!!"

报告还包括ALSO IN THE REPORT

IT 治理评估 · 内部控制评估（备份失败率 29.4%，行业标准为 5% 以内）· 客户数据共享的伦理建议 · 工具：SQL（PostgreSQL）、舞弊三角模型、COSO 内控框架IT governance review · internal control review (29.4% backup failure rate vs a 5% norm) · ethics advice on sharing customer data · Tools: SQL (PostgreSQL), fraud triangle, COSO

左右滑动 · 点击放大 · Swipe · tap to zoom · 报告原图：付款分布 · 可疑供应商 · 假员工 · 越权审批 · SQL 脚本From the report: payment spread · suspicious vendors · ghost staff · unauthorised approvals · SQL

舞弊资金合计Total fraud

$983,781

10 家假供应商 · $793,65210 fake vendors · $793,652

5 名假员工 · $163,822 / 年5 ghost employees · $163,822 a year

9 笔半额重复付款 · $22,9599 half-amount duplicate payments · $22,959

其他违规付款 · 约 $3,300Other irregular payments · ~$3,300

1,119 笔付款，最高一笔也"刚好"低于审批线1,119 payments; even the largest sits just under the approval limit

审批线Approval limit$10,000

最高单笔Largest$9,969

根据报告数据绘制。公司与数据均为课程模拟。Drawn from the report's figures. Company and data are simulated for the course.

课程项目 · 昆士兰大学Course project · UQ2026.04–2026.06数据运营Data operations成绩 29/30（HD）Grade 29/30 (HD)

电商数据仓库与经营分析看板E-commerce data warehouse & dashboard

把散落在多个系统里的销售、客户、商品和供应商数据统一口径、整合到一起，做成可以随时筛选的经营看板。I brought sales, customer, product and supplier data from several systems onto one consistent definition and built a dashboard anyone can filter.

2.5 万25K条销售记录sales records

2.1 万21K名客户customers

2,199款商品，另有 100 家供应商products, plus 100 suppliers

29/30课程成绩（HD，最高等级）grade (HD, top band)

项目背景CONTEXT

电商企业的销售、客户、商品和供应商数据分散在不同系统中，同一指标在不同报表里口径不一，跨表回答一个经营问题往往要手工拼表、反复核对。目标是搭建统一的数据仓库和经营看板，让业务人员能自助查看、按需筛选。The retailer's sales, customer, product and supplier data sat in separate systems, and the same metric meant different things in different reports, so answering one business question meant stitching tables together by hand. The goal was a single data warehouse and dashboard that business users could explore and filter themselves.

项目成果OUTCOME

一份统一口径的经营数据集，不同部门不再各算各的One consistent dataset so teams stop working from different numbers
一个看得懂的看板，支持商品复盘和供应商评估A readable dashboard for product reviews and supplier assessment
课程成绩 29/30（HD）Grade 29/30 (HD)

我做了什么WHAT I DID

运营需求分析：从运营视角梳理出销售趋势、商品表现、客户结构、供应商管理 4 类分析需求，并按使用者拆成两套看板：商家视角（卖得怎么样、哪些商品该补该清、哪些供应商值得长期合作）和客户视角（客户是谁、偏好什么、消费水平如何），作为数据模型和指标设计的依据。Operating needs: framed four analysis needs (sales trends, product performance, customer mix, supplier management) and split them by user into a merchant view (how sales are going, what to restock or clear, which suppliers to keep) and a customer view (who customers are, what they prefer, how much they spend), which shaped the data model and metrics.
数据治理与 ETL：用 SSIS 搭建 ETL 流程，把多来源业务数据抽取、清洗后加载进 SQL Server；统一商品、客户、供应商等关键字段的编码与口径，完成约 2.5 万条销售记录、2.1 万名客户、2,199 款商品和 100 家供应商的清洗、匹配与关联，形成一份统一口径的经营数据集，避免不同部门各算各的。Data governance & ETL: built SSIS pipelines to extract, clean and load multi-source data into SQL Server; aligned codes and definitions for products, customers and suppliers across ~25K sales, 21K customers, 2,199 products and 100 suppliers, producing one consistent dataset so teams stop working from different numbers.
看板搭建与分析：用 Power BI 搭建商家视角和客户视角两套看板，覆盖销售概览、商品表现、客户分析、供应商结构 4 个模块，支持按时间、商品、供应商等多维度筛选；并用 R 做补充分析，辅助商品复盘与供应商评估。Dashboards & analysis: built merchant and customer dashboards in Power BI covering sales overview, product performance, customer analysis and supplier mix, filterable by time, product and supplier, with supporting analysis in R for product reviews and supplier assessment.

从分散的数据，到一个经营看板From scattered data to one dashboard

25K条销售记录sales records

21K名客户customers

2,199款商品products

100家供应商suppliers

↓

SSIS 清洗匹配 → SQL Server 统一口径数据集SSIS cleaning → one consistent SQL Server dataset

↓

商家视角看板Merchant view销售 · 商品 · 供应商Sales · products · suppliers

客户视角看板Customer view客户结构 · 购买偏好Customer mix · preferences

用 Power BI 搭建，支持多维度筛选，R 做补充分析Built in Power BI with multi-dimension filters; R for supporting analysis

项目结构示意图Project structure

商家视角看板Merchant view

时间Time商品Product供应商Supplier

销售额Revenue

订单数Orders

客单价Avg. order

销售趋势Sales trend

商品表现 TopTop products

供应商结构Supplier mix

卖得怎么样、哪些商品该补该清、哪些供应商值得长期合作How sales are going, which products to restock or clear, which suppliers to keep

客户视角看板Customer view

时间Time地区Region客户类型Segment

客户数Customers

人均消费Spend / customer

购买频次Purchase frequency

消费水平分布Spend distribution

客户结构Customer mix

购买偏好Category preference

客户是谁、喜欢买什么、消费水平如何Who the customers are, what they buy, how much they spend

项目使用真实商户数据，出于数据保密要求，原始看板不便公开展示。以上为根据看板结构绘制的示意图。This project used real merchant data, so the original dashboards can't be shown publicly for confidentiality reasons. The sketches above follow the dashboards' structure.

国际竞赛 · 线上Global contest · online2024.06团队总负责人Team lead7 国成员7 countries

GEE 全球企业体验大赛 · 植物保护无人机Global Enterprise Experience · Plant Protection Drone

3 周内带领来自 7 个国家的线上团队，从零做出一份完整的商业方案，在 170 余支队伍中排名第 5。In three weeks I led an online team from seven countries to build a complete business proposal from scratch, placing 5th of 170+ teams.

第 55th170+ 支队伍中（前 3%）of 170+ teams (top 3%)

7个国家的团队成员countries on the team

3 周3 wks从组队到交付from kick-off to delivery

11个实体的数据模型entities in the data model

项目背景CONTEXT

GEE（Global Enterprise Experience，全球企业体验大赛）是新西兰发起的国际线上商业创业竞赛，由 Windeaters 与惠灵顿维多利亚大学合办。赛题是：用有限的资本，做一个能推动联合国可持续发展目标的盈利项目。每支队伍 8 人，来自不同国家和时区，全程线上协作。GEE is an international online business competition founded in New Zealand and run by Windeaters with Victoria University of Wellington. The brief: a profitable venture that advances a UN Sustainable Development Goal with limited capital. Each team of eight spans countries and time zones and works entirely online.

项目成果OUTCOME

“植物保护无人机”方案在 170 余支队伍中排名第 5（前 3%）“Plant Protection Drone” placed 5th of 170+ teams (top 3%)
获赛事官方推荐信和创业基金Official letter of commendation and start-up funding

我做了什么WHAT I DID

跨国团队协作：负责团队的任务重组，梳理成员分工、交付节点和具体交付物，并通过 Teams、WhatsApp 和邮件跟进进度，3 周内推动团队按计划完成方案设计和最终交付。Cross-border teamwork: reorganised tasks, set owners, milestones and deliverables, and tracked progress over Teams, WhatsApp and email to deliver on plan within three weeks.
商业方案设计：围绕赞比亚的农作物保护场景，带领团队完成市场需求、产品定位、收入预测和基础盈利能力分析，形成“植物保护无人机”商业方案。Business plan: for crop protection in Zambia, led market sizing, positioning, revenue forecasting and profitability analysis into the “Plant Protection Drone” proposal.
数据模型搭建：用 ERD 设计包含 11 个实体的数据模型，分为成本、市场和无人机三个模块，以一对多关系串联，作为支撑文档提交评审，并作为汇报人参与最终汇报。Data model: designed an 11-entity ERD in three modules (cost, market, drone) linked one-to-many, submitted as supporting evidence; presented the final pitch.
竞赛方案交付：搭建成本结构和定价模型，完成收入预测和基础盈利能力评估。Financials: built the cost structure and pricing model for the revenue forecast and profitability assessment.

左右滑动 · 点击放大 · Swipe · tap to zoom · 参赛证书 · 官方推荐信（GEE 2024）Certificate · letter of commendation (GEE 2024)

你好，我是肖艺宣Hi, I'm Yixuan Xiao

项目合集Projects

FlowPilot Lab · 供应链计划与决策平台FlowPilot Lab · Supply-chain planning platform

项目背景CONTEXT

项目成果OUTCOME

我做了什么WHAT I DID

该如何判断优先级？How do you decide what comes first?

如果重做，我会怎么改What I'd do differently

业务流程图：系统实际处理的范围PROCESS DIAGRAMS: WHAT THE SYSTEM ACTUALLY HANDLES

在线 Demo：打开即可体验Live demo: open and click around

PawPath · 动物收容与领养管理平台PawPath · Animal shelter & adoption platform

项目背景CONTEXT

项目成果OUTCOME

我做了什么WHAT I DID

需求建模基本功能力展示REQUIREMENTS MODELLING FUNDAMENTALS

在线 Demo 制作中Live demo coming soon

AI 旅行规划师AI Travel Planner

项目背景CONTEXT

项目成果OUTCOME

我负责的部分MY PART

团队共同实现BUILT BY THE TEAM

系统流程：AI 和算法各管什么HOW IT WORKS: WHAT AI DOES, WHAT ALGORITHMS DO

PM/BA Panda · 从需求到原型的 Claude SkillPM/BA Panda · A Claude Skill from requirements to prototype

和直接让 AI 写有什么不同WHY NOT JUST ASK AI TO BUILD IT

诚实的边界HONEST LIMITS

用起来是什么样WHAT USING IT LOOKS LIKE

我做了什么WHAT I DID

贷款违约风险分析Loan default risk analysis

决策树Decision tree

逻辑回归Logistic regression

一个住址，串起约 98 万美元的舞弊链One address, a US$980K fraud scheme

项目背景CONTEXT

体现的能力WHAT IT SHOWS

报告还包括ALSO IN THE REPORT

电商数据仓库与经营分析看板E-commerce data warehouse & dashboard

项目背景CONTEXT

项目成果OUTCOME

我做了什么WHAT I DID

GEE 全球企业体验大赛 · 植物保护无人机Global Enterprise Experience · Plant Protection Drone

项目背景CONTEXT

项目成果OUTCOME

我做了什么WHAT I DID

我的学习工作经历My education & work journey

奥塔哥大学 · 会计学学士University of Otago · BCom Accounting

GEE 国际商业竞赛GEE International Business Competition

安永华明会计师事务所EY (Ernst & Young Hua Ming)

昆士兰大学 · 信息系统硕士University of Queensland · MS Information Systems

微创网络（Wicresoft）Wicresoft

期待加入你的团队Hoping to join your team

工作之外的我Outside of work

🍠 地瓜 · 我的原创 IPDigua · my original character

兴趣爱好Interests

我的工作习惯My working habits

01. 先理解问题，再开始行动Problem first

02. 把复杂任务拆成可执行的步骤Structured execution

03. 不只追求完成，还要验证结果Validate before trusting

04. 主动沟通，尊重不同观点Communicate with clarity

05. 接受反馈，持续迭代Iterate and improve

06. 保持学习，并将知识用于实践Learn by building